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FOREWORD 


This document represents one Section of the FINAL REPORT for the STS 
PAYLOADS MISSION CONTROL STUDY CONTINUATION PHASE A-1 , prepared by TRW 
Defense and Space Systems Group under Contract NAS9-14484, with NASA, 
Lyndon B. Johnson Space Center. The complete list of documents that 
comprise the FINAL REPORT of this Study is as follows: 

• Volume I - Integrating Summary Report 

• Volume I I -A - Study Task 1 - Joint Products and Functions 

for Preflight Planning of Flight Operations, 
Training and Simulations 

*t Volume II-B - Study Task 2 - Evaluation and Refinement of 
Implementation Guidelines for the Selected 
STS Payload Operator Concept 

• Volume II-C - Study Task 3 - Joint Preflight Activities in 

Preparation for STS Payload Flight Operations 
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2.0 EVALUATION AND REFINEMENT OF IMPLEMENTATION GUIDELINES FOR THE 

SELECTED STS PAYLOAD OPERATOR CONCEPT (TASK 2) 

NASA selected a preferred flight control concept for STS payloads 
front the basic study and TRW provided general guidelines for implementa- 
tion during 1980 through 1991. This follow-on study evaluates and refines 
those implementation guidelines with emphasis on standardized approaches 
(Subtask 2A) and definition of operational interfaces between STS Operator 
and Payload Operator elements (Subtask 2B), 

2.1 DEFINE APPROACHES TO PAYLOAD- OPERATOR CONTROL CENTER (POCC) DEVELOP- 
MENT THAT ENCOURAGE EARLY STANDARDIZATION AND FACILITATE NASA-WIDE 

SYSTEM OF POCC'S (SUBTASK 2A) 

The purpose of Subtask 2A is to define approaches to Payload Operations 
Control Center (POCC) development that will permit early standardization 
of system architecture and Identify systems that will facilitate the 
earliest achievement of a fully integrated NASA-wide system of STS POCC's. 

2.1.1 Introduction 

With the advent of the Space Transportation System (STS), future pay- 
loads will benefit from economical and highly standardized methods of 
la,unch into orbit, servicing and systems support on-orbit, and retrieval, 
as required by the specific missions. 

In addition to the standard operations made possible by the STS, GSFC 
will make available a standard "bus" for free- flying payloads through the 
design of a multi -mission modular spacecraft. 

With the steps being taken toward standanilzation of launch vehicles, 
powered upper stages, Spacelab payload support systems and large automated 
spacecraft for free-flyers, it seems logical that the ground facilities for 
support of STS payloads should evolve toward a Standard Payload Operations 
Control Center (SPOCC), 

This subtask addresses the approach to optimum standardization of 
POCC's for all classes of payloads. 
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2. 1.1.1 Study Guidelines for Subtask 2A . 

In addition, to the guidelines -for the study, the following special 
guidelines have been used for Subtask 2A. 

■ a. fhe target date for completion of implementation of POCC 

standardization is mid-1982 since this is approximately the 
50-percent point in achieving the traffic model flight rate. 

b. The OFT flights have not been considered from the standpoint of 
POCC implementation 

*c. OSC, GSFC and JPL have been designated as the primary NASA- Payload 
Operations Centers (POC's) for Spacelab, Automated Earth Orbit 
(including geosynchronous), and Planetary, respectively. 

d’. It is assumed that existing POCC's at JSC, GSFC and JPL along with 
existing plans for augmentation will be sufficient to. handle pay- 
load traffic. This study addresses the evolutionary change-over 
to standardization and improvement of efficiency, with the atten- 
dant-potential cost savings, rather than the sufficiency of the 
existing and planned capabilities of the Centers to meet func- 
tional requirements. 


*Note ; Definition of POCC versus POC . A Payload Operations Control Center 
XpOCC) Ts "the point of payload flight operations, typically 
a room equipped with controls and displays, telephones, etc, and 
constitutes one element of a Payload Operations Center (POC). The 
POC, i.e., JSC (Spacelab), GSFC (Automated Earth Orbit-LEO and GEO) 
or JPL (Planetary) also provides other capabilities, such as 
Experiment Data Processing, Flight Maneuver Computations, Orbit 
Determination,- etc. , in addition to the POCC’s. 
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2,1.2 Approach to PQCC Development 

Task f of the basic study has defined general guidelines for an 
implementation plan for STS Payload Flight Control with special em- 
phasis on the Payload Operation Control Center, Utilizing the same 
representative payloads, flight types and primary NASA Centers addressed 
in the basic study, the objective of Subtask 2A is to refine and detail 
the implementation guidelines for cost effective Payload Operations 
Control Centers (POCC's). 

An approach to POCC design and development will be presented using 
maximum practical standardization of system architecture, software 
and hardware leading to the concept of the optimally Standard POCC 
(SPOCC) including both common and unique POCC functions. A typical 
SPOCC associated with any one of the three primary NASA Centers, 
namely JSC, GSFC and JPL, will consist of the same common POCC functions 
augmented by a variable subset of unique payload and experiment dependent 
functions. The following study will define the functional characteris- 
tics of the Standard POCC and attempt to identify the common functions . 
as well as the various subsets of unique functions relative to each 
POCC type based on presently planned payload requirements. 

2. 1,2.1 Approaches to POCC Standardization 

A key concept formulated in the basic study toward implementing 
a cost effective NASA-wide POCC System for STS payloads 1s the idea 
of POCC standardization. The concept becomes more attractive for 
operations during the later years of the STS era when payloads are 
launched more frequently, are of a longer duration and require a 
greater extant of processing capability and interface control. Under 
these circumstances, the idea of payload-dedicated POCC's is no longer 
justifiable. Especially from a cost point of view, some level of POCC 
standardization is necessary to allow for simple and relatively inexpensive 
design, development and upgrading of the capabilities for the required 
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network of POCC's. POCC standardization offers the advantages of a 
simple, efficient, cost-effective approach for POCC development to 
meet increased loading requirements. 

There are various ways of achieving POCC standardization 

a. Functional standardization where an attempt is made to- stan- 

dardize the majority of POCC functions. A small percentage 
of functions are assumed unique to the class of payload arid 
nature of the experiments. ; 

r 

b. Procedural standardization where operational procedures to 
monitor, command and control the payload and to a certain 
extent the experiment are standardized. Included in such a 
standardization are the command, and- control philosophy; pay- 
load command sequences with respect to flight type, experi- 
mental procedures with respect to scientific experiments, and 
the man-machine interface. 

c. Hardware configuration standardization where the processing 
hardware and peripherals, hardware interfaces and essentially 
the POCC hardware architecture are standardized-. 

d. Communication standardization where an attempt is made- to stan- 
dardiz'e 'all external interfaces to the NASA Centers as much as 
practically possible, leading to a common communication net- 
work with standards for communications, transfer protocols and 
data formats. 

e. Standardization relative to primary payloads of interest . 

All GSFC POCC's would be primarily standardized to handle 
Automated Earth Orbit payloads. All JSC POCC's would be 
primarily standardized to handle Spacelab payloads. All JPL 
POCC's would be primarily standardized to handle 'Planetary 
payloads. A secondary objective might be to allow. POCC's, for 
each POC, the capability to handle to some extent another pay- 
load class not assigned to that Center on a primary basis.. ' 

.Full POCC standardization, consisting of a mix of the various con- 
cepts presented in this paragraph and allowing- each POCC to handle any 
payload, is not practically advantageous due to cost, added inflex- 
ibility, especially from a user's point of view, and extensive planning 
and development effort. 
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The approach to be taken in this subtask will be to find the opti- 
mum limited standardization approach assuming the .planned payload types, 
the -number and duration of the payload flights, the present POCC 
capabilities, the desired POCC objectives and the allowable timeframe- 
for POCC development. 

The objectives here are to lay the ground rules for functional 
standardization for all primary POCC's aiming toward standard data 
processing software and standard architecture for processing hardware 
and peripherals, and present a plan for SPOCC system development. 
Standardization will be primarily directed toward POCC's of the same 
class, i.e., Spacelab, Automated Earth Orbiting- or Planetary. Limited 
functional standardization will be applied to these POCC's and their 
independent capability to handle primary as well as secondary payloads 
will be explored. 

2, 1.2. 2 POCC Functional Standardization 

In order to perform the desired functional- standardization and 
derive a model for a standard POCC (SPOCC), all' functions allocated 
to the POCC versus the STS Flight Operator, should be reviewed for 
all planned payloads and experiments and for. each of the three POCC 
classes. For each class, common and unique functions should be identi- 
fied, resulting in a model for the standard POCC for each POCC class. 

The three standard POCC models should then be further analyzed 
for functional commonality leading toward a unique POCC model for all 
POCC classes. The common functions of this model should be common for 
all POCC's. This standard POCC model could be ideally used in 
the development of a cost-effective NASA-v/ide network of Payload Oper- 
ation.. Control Centers. 

As a guideline for this subtask, we are going to consider only the 
three primary NASA Centers, namely JSC, GSFC and JPL, and assume that 
all planned payloads are essentially allocated among these three Centers. 
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Non-NASA payloads are allocated to a unique non-NASA facility. 

Figure 2.1-1 shows the three NASA Centers and the payloads allocated 
to each. In this payload model, GSFC is assumed to be the primary 
payload operator for Automated Earth Orbiting payloads, JSC for Space! ab 
payloads and JPL for Planetary payloads. Figure 2,1-2 indicates the 
related POCC versus Flight Phase activity matrix. This matrix has been 
expanded to include not only the support of primary payload classes 
assigned, but secondary or backup POCC support to another Center. 

2. 1.2. 2.1 POCC Functions 

A review of all planned payloads was performed to identify top 
level POCC functions required for payload operation. All payload- 
related ground functions were identified. 

The following is a list of major POCC functional areas; 

a. Data Processing Executive Function which controls all data 
processing activities and supports all application functions. 

b. Communication function which specifies ground rules for data 
transfer and coordinates all data communications external to 
a POCC. 


c. Data Base Management Function which maintains the POCC data 
bases. 

d. Man-Machine Interface Functions which control and coordinate 
all man-machine interactions. 

e. Simulation Function responsible for providing drivers and 
algorithms for simulation of engineering subsystems, experimental 
procedure and mission plans, 

f. Testing Function responsible for POCC subsystems, communications 
network, payload spacecraft and experimental subsystems checkouts. 

g. Mission Planning consisting of all preflight planning activities 
in support of payload operations. 

h. Flight Support Function which supports the STS Operator functions 
during Orbiter flight and analyzes Orbiter flight data; it also 
provides support for POC processing of tracking data, attitude 
and orbit data, flight maneuvers computations and ephemeris data. 
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FLIGHT TYPE 


SPACELAB 


AUTOMATED EARTH ORBIT 
(LEO ONLY} .. 


AUTOMATED lUS/SSUS/TUG 
(AEO/GEO/PLANETARY} 


PRIMARY 

POCC 

LOCATIONS 



NON-NASA 


AEO - AUTOMATED EARTH ORBIT . 

GEO - GEOSYNCHRONOUS EARTH ORBIT 
LEO - LOW EARTH ORBIT 


* J IS A "MULTI-CARGO ".FLIGHT, CONTAINING SPACELAB LS WITH AEO DELIVERIES OF EXPLORER AND STP (OOD). 
**'L AND H, ARE PLANETARY', .K AND M ARE MULTI-SATELLITE, ALSO REQUIRING POWERED. UPPER STAGE, , 


Figure 2.1-1. Payload Supported by Primary POCC's 
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LEGEND:' 'P = PRIMARY, B = BACKUP’ POCC ' ' " 

Figure E.l-Z. POCC Support by Flight Phase, Activity Matrix - Primary and 
Backup POCC's 




■i.. . Payload Operation and' Control Function "which monitors all 
'■ payload spacecraft engineering subsystems, analyzes spacecraft 
condition, and initiates and controls spacecraft guidance 
activities (in our-.conte'xt payload "is synonymous to spacecraft 
■which houses all the engineering and experiment subsystems). 

t - r • < * » 

. • / - , / 

j. Payload Command Function responsible for the generation of all 
payload commands for ‘the spacecraft as vyelT. as the experiment. 

■k. -Telemetry Function -responsible for the monitoring and pre- 
processing -of telemetry data. ■ 

l. Experiment Operation and Control Function which monitors 

the experimental data, controls and* coordinates the experimental 
activities and preprocesses the scientific data-. 

m. - Status Monitoring Function, responsible for 'keeping track of 

the status of the entire payload system and- operation, and 
related ground stations. 

' 2, 1,2, 2, 1,1 Common POCC Functions 

• ■ Following the review, of POCC functional areas, all similar functions 

were grouped into representative subsets for each of the three major 
■payload classes" separately. . 

Similar subsets for. all three classes were analyzed for commonality. 
Similar functions withi.n, subsets were grouped., .leading to sets of func- 
tions common to all payloads irrespective of payload class. 


The following is a summary list of functions -common to all POCC's; 

a. Data Processing (DP) Operating System comprising the executive 
for data processing including task scheduling, interrupt handling 
error recovery, and peripheral coordination. 

b. Communication Processing consisting of monitoring all com- 

munication interfaces, maintaining the communication integ- 
rity and preprocessing communication data; and pe.rforming 
network control . . . ■ . 

c. Data Base Management capable of supporting local as well as 
centralized data base creation, maintenance and update. 

d. Man-Machine Interface comprising operator command valida- 
tion and display formatting into a standard set of formats. 


o n 


e. Simulation of standard payload engineering .and scientific sub- 
system models for operator .training and system' exercise. 

f. Testing of standard system operational procedures, engineer- 
ing subsystems and scientific equipments through generation 
of standard test commands and analysis of test data. 

g. Off-line Mission Planning comprising the analysis of external 
support, user requirements and Orb iter/ payload system; gener- 
ation of standard mission, and contingency plans, command 
sequences, experimental schedules and development of standard 
operational procedures. 

h. Flight support providing standard support to the STS Operator; 
ana.lyzing Orbiter flight data; monitoring and evaluating 

POC processed data such as payload ephemeris, attitude and 
• . orbit data, tracking and flight maneuver data; monitoring pay- 
load/Orbiter function and 'status, 

1. Payload Operation and Control comprising the monitoring and 

analysis of standard payload spacecraft engineering functions and 
subsystems; controlling the operation and guidance of the 
spacecraft, evaluating spacecraft condition;- monitoring and 
coordinati.ng the payload mission, 

j. Payload Command Processing consisting of the standard' genera- 
tion and monitoring of outgoing payload commands. 

k. Telemetry Data Processing consisting of the. standard moni- 
toring and preprocessing of incoming telemetry data. 

l. Experiment Operation and Control including the' monitoring 
of standard scientific equipment, the control, of standard 
experimental procedures and the gross analysis of experi- 
mental data. 

m. Status monitoring of the entire system; supervising data 
recordings; maintaining system logs; and generating per- 
formance plots. 

These common payload functions are covered in greater detail in 
Tables 2.1a through 2 . 11 . 
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TABLE 2.1a. COMMON* PAYLOAD OPERATION CONTROL FUNCTIONS - DP OPERATING SYSTEM 


• EXECUTIVE CONTROL 

• TASK SCHEDULING 

• PROCESS INITIALIZATION/TERMINATION 

• INTERRUPT HANDLING 

• TASK PRIORITY SELECTION/ ASSIGNMENT 

• MONITOR/COORDINATE PERIPHERAL I/O 

• ERROR PROCESSING AND RECOVERY 

• DATA RECORDING AND LOGGING 

• DATA BASE MANAGEMENT EXECUTIVE 

• BACKGROUND/FOREGROUND PROCESSING CAPABILITY 

• DP SUBSYSTEM STATUS MONITORING 

■ > • OPERATING SYSTEM SECURITY 

* COMMON MEANS COMMON TO ALL PAYLOADS REGARDLESS OF GLASS. 





TABLE 2.1b. COmON* PAYLOAD OPERATION CONTROL FUNCTIONS COMMUNICATION PROCESSING 

• MONITOR COMMUNICATION INTERFACES 

• MONITOR GROUND/ PAY LOAD COMMUNICATIONS 

• MONITOR aLl user INTERFACES 

• MONITOR COMMUNICATION WITH ALL POCC'S AND FLIGHT CONTROL CENTERS 

• MAINTAIN COMMUNICATION LINE INTEGRITY 

• MAINTAIN COMMUNICATION PROTOCOL 

t HANDSHAKING 

• MONITOR TRANSMISSION ERRORS ■ 

• REQUEST/ INITIATE RETRANSMISSIONS 

• LOG COMMUNICATION DATA ' 

• PREPROCESS COMMUNICATION DATA 

• VALIDATE/ DECODE INPUT DATA 

• FORMAT/ COMPRESS OUTPUT DATA 

• MULTIPLEXING AND DEMULTIPLEXING 

• STRIP PAYLOAD DATA 

• ROUTE FOR RECORDING AND PLAYBACK 

• TEST ALL COMMUNICATION LINES, 

• PROVIDE CAPABILITY FOR 

■# CONFIGURATION CHANGES 

• PROTOCOL .MODIFICATION 

* COMMON MEANS COMMON TO ALL PAYLOADS REGARDLESS OF CLASS. 
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TABLE 2.1c. COMMON* PAYLOAD OPERATION CONTROL FUNCtlONS - DATA BASE MANAGEMENT 

• FILE DEFINITION. AND CREATION 

; FILE DiRE'dTORY PROCESSING} 

• FILE ADDRESSING/SEARCHING 

• DATA STORAGE AND^RETRIEVAL 

• MAINTAIN DATA B'ASEMNTEGRITY' ANQ SECURITY 

• LOG DATA BASE ACTIVITY : 

j ’ 

• SUPPORT DISTRIBUTIVE/ CENTRALIZED DATA BASE 

• MULTIPLE USER ACCESS 

• ON-LINE AND' BATCH iDATA BASE' PROCESSINGS 

• SUPPORT AUTOMATED OFF-LINE" DATA PRINTOUT 

•" COMMON DATA BASE CONTENT 

t PAYLOAD OPERATION/PGINEERING DATA 

• PAYLOAD ixpE'RIMENt 'DATA' 

e PAYLOAD TELEMETRY 'DATA ' 

• MISSlbN/FLiGHrpLANS"' ' ' 

PAYLOAD COMMANDS 

• SYSTEM, PAYLOAD AND EXPERIMENT STATUS INFORMATION 

*COMMON MEANS COMMON TO' ALL/PAYLOADS REGARDLESS OF CLASS. . " . , • . 
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TABLE, 2. Id. \ COMMON* PAYLOAD OPERATION .CONTROL FUNCTIONS - MAN-MACHINE INTERFACE 






*coMmon 


OPERATOR COMMAND PROCESSING 

'• ■ Accept AND validate operator commands 

' f ’PREPROCESS AND ' EDIT OPERATOR MESSAGES 

• format OPERATOR COMMANDS 

• LOG OPERATOR COMMANDS 

DISPLAY GENERATION 

§ DISPLAY FORMATTING 

• ‘ .REAL TIME DISPLAY 'GENERATION 

- TELEMETRY DATA 
’ . - SYSTEM STATUS 

. . _ - tabular data . . 

•' BACKGROUND DISPLAY GENERATION 

• . ALARM OENERATION 

• SELECTIVE DISPLAY UPDATE/ERASE 
V DISPLAY MONITORING 

MONITORING OF ALL MAN-MACHINE INTERACTIONS 


MEANS ‘common TO ALL'’’’ PAYLOADS REGARDLESS OF CLASS. 
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TABLE 2.1e. COMMON* PAYLOAD OPERATION CONTROL FUNCTIONS - SIMULATION AND TRAINING 


• ON-LINE SIMULATION FOR: 

• SYSTEM EXERCISING 

• • PERSONNEL TRAINING 

• ' OPERATIONAL PROCEDURE VERIFICATION 

• MISSION/ FLIGHT PLANS VALIDATION 

• ..OFF-LINE SIMULATION TO DEBUG' OPERATIONAL SOFTWARE 

SIMULATE OPERATIONALLY CRITICAL PAYLOAD' SUBSYSTEMS 

• SIMULATE MALFUNCTIONS AND- ANOMALIES 

I ‘ 

• SIMULATE EXTERNAL INTERFACES 

• S-IMULATE STANDARD ENGINEERING- AND SCIENTIFIC SUBSYSTEM MODELS 

t SIMULATE PAYLOAD MISSION/FLIGHT' PLANS 


*COMMON MEANS COMMON TO ALL PAYLOADS RE.GARDLESS OF CLASS. 
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TABLE 2.'lf. COMMON* PAYLOAD OPERATION CONTROL FUNCTIONS - TESTING AND CHECKOUT 


•• STANDARD TESTING OF SYSTEM OPERATION, PROCEDURES AND SUBSYSTEMS 

• TEST ALL COMMUNICATION INTERFACES 

• ENGINEERING SUBSYSTEMS 

• ■ SCIENTIFIC EQUIPMENT 

• REAL-TIME AUTOMATIC/ MAN UAL PAYLOAD CHECKOUT 

• TEST DATA ANALYSIS 

• MONITOR AND LOG TEST FAILURES 

• PAYLOAD OPERATIONAL READINESS VERIFICATION 

GENERATION OF STANDARD TEST COMMANDS 


*COMMON MEANS COMMON TO ALL' PAYLOADS REGARDLESS OF CLASS. 



TABLE 2. 










t 




■f 


, COMHON* PAYLOAD OPERATION CONTROL FUNCTIONS - MISSION PLANNING/FLIGHT PLANNING 


USER/EXPERIMENT REQUIREMENTS ANALYSIS 
ANALYSIS OF EXTERNAL RESOURCE AND PLANNED SUPPORT 
TECHNICAL EVALUATION OF SPACECRAFT/PAYLOAD SYSTEMS 
OFF-LINE GENERATION OF: 

• ■ PAYLOAD/EKPERIMENT OPERATIONS PLANS AND SCHEDULING 

• CONTINGENCY PLANS 

• MISSION OR FLIGHT/COMMAND TIMELINE, SEQUENCE AND PROFILES 
_ • SIMULATION MODELS 

• PERFORMANCE CRITERIA 

• ENERGY CONSUMPTION PROFILES 

ANALYSIS OF FUNCTIONAL SIMULATOR RESULTS 

ON-LINE REAL-TIME UPDATE OF PAYLOAD/EXPERIMENT PLANS 

OPERATIONAL PROCEDURE DEVELOPMENT 


*COMMON MEANS COMMON TO ALL PAYLOADS REGARDLESS OF CLASS 
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TABLE 








t 


t 






*COMMON 


:.lh. COMMON* PAYLOAD OPERATION CONTROL FUNCTIONS - FLIGHT SUPPORT 

MONITOR SUPPORT SPACECRAFT/PAYLOAD DURING ORBITER FLIGHT 
ORBITER FLIGHT DATA MONITORING AND QUICK-LOOK ANALYSIS 

SUPPORT TRACKING DATA ANALYSIS AND ORBIT DETERMINATION 

• QUICK-LOOK ANALYSIS OF TRACK DATA 

SUPPORT Attitude data processing 

• ' . PREPROCESS' ATTITUDE SENSOR DATA 

t MONITOR' RAW ATTITUDE DATA QUALITY • 

• MONITOR/EVAluATEPOC attitude PREDICTIONS 

SUPPORT FLIGHT MANEUVER DATA PROCESSING 

<■1 I 

• MONITOR/ EVALUATE POC PROCESSED FLIGHT MANEUVER DATA 

SUPPORT PAYLOAD EP.HEMERIS DATA PROCESSING' 

• MONITOR/ EVALUATE -POC PROCESSED EPHEMERIS DATA 

MONITOR PAYLOAD DEPLOYMENT 

■, T,- •> 

MONITOR ORB ITER/PAYLOAD HANDOVERS 

MEANS COMMON TO ALL PAYLOADS REGAR.DLESS OF CLASS. 
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TABLE 2,li. COflUON* PAYLOAD OPERATION CONTROL FUNCTIONS - PAYLOAD OPERATION AND CONTROL. 

• PAYLOAD CONTROL 

• REAL-TIME CONTROL OF PAYLOAD OPERATIONS DURING ALL PHASES 

• EXECUTE/ COORDINATE PLANNED PAYLOAD OPERATION SEQUENCE 
f INITIATE CONTINGENCY PLANS FOR EMERGENCY SITUATIONS 

• GO/NO-GO DECISION FOR CONTINUING NISSION/FLIGHT 

• PAYLOAD ACTIVATION/RECONFIGURATION/DEACTIVATION 

§ STIMULATE PAYLOAD COMMANDS 

f CONSUMABLES ANALYSIS 

• PAYLOAD ENGINEERING ANALYSIS 

• VERIFY PAYLOAD DATA 

- VERIFY PAYLOAD EPHEMERIS AND ORIENTATION 

- VERIFY PAYLOAD ALIGNMENT MECHANISM 

- VERIFY PAYLOAD MANEUVER REQUIREMENTS 

f MONITOR CONSUMABLES 

• MONITOR PAYLOAD PYROTECHNICS FOR NON-ARMED CONDITION 

• ANALYZE, SET-UP AND CALIBRATE- PAYLOAD SUBSYSTEMS 

• VERIFY GROUND SYSTEM PERFORMANCE 

• PAYLOAD GUIDANCE 

• PAYLOAD STATUS MONITORING 

• MONITOR CRITICAL PAYLOAD FUNCTIONS 

t MONITOR PAYLOAD FUNCTIONAL AND OPERATIONAL STATUS 

• ANALYZE AND ISOLATE PAYLOAD FAULTS AND ANOMALIES 

• CHECKOUT PAYLOAD EQUIPMENT 

• MAINTAIN ENGINEERING AND OPERATION RECORDS 

• MONITOR PAYLOAD DEPLOYMENT 

*CpMMON MEANS COMMON TO ALL PAYLOADS REGARDLESS OF CLASS. 
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TABLE 2.,lj. COMMON* PAYLOAD OPERATION CONTROL FUNCTIONS - PAYLOAD COMMAND PROCESSING 


• MONITOR PAYLOAD COMMAND SEQUENCE 


t MAINTAIN COMMAND LOG AND COMMAND MASTER DATA RECORD 


•• COMMAND GENERATION 

• PREPARE COMMAND SEQUENCE 

• COMMAND ENCODING AND FORMATTING 

• COMMAND VERIFICATION 

• INITIATE COMMAND TRANSMISSION 


• COMMON PAYLOAD COMMANDS 

• PAYLOAD FLIGHT SUPPORT COMMANDS 

• STANDARD PAYLOAD OPERATION AND CONTROL COMMANDS 

• STANDARD EXPERIMENT RELATED COMMANDS 

• PAYLOAD STATUS MONITORING COMMANDS 


*COMMON MEANS COMMON TO ALL PAYLOADS REGARDLESS OF CLASS. 



2-21 


TABLE ' 2 . 










Ik. ■ COMflON* PAYLOAD OPERATION CONTROL FUNCTIONS - TELEMETRY DATA PROCESSING 


MONITOR PAYLOAD TELEMETRY 


PREPROCESS TELEMETRY DATA 

• , ACCEPT AND VALIDATE DATA 

• REFORMAT DATA 

t DE COMMUTATE DATA 

• PERFORM REDUNDANCY CHECKS 

• DETECT FRAME SYNC PATTERN 


RECORD AND LOG TELEMETRY DATA 

SUPPORT PAYLOAD, EPHEMERIS, DATA PROCESSING 

• PROCESS EPHEMERIS DATA 

• VERIFY SATISFACTORY PAYLOAD EPHEMERIS AND ORIENTATION 


*COMMON MEANS COMMON TO ALL PAYLOADS REGARDLESS- OF CLASS 
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TABLE 2.U. COMMON* PAYLOAD OPERATION CONTROL FUNCTIONS - EXPERIMENT OPERATION AND CONTROL . 


EXPERIMENT MONITOR AND CONTROL 

f MONITOR SCIENTIFIC INSTRUMENTS PARAMETERS 

t EXECUTE/COORDINATE PLANNED EXPERIMENT SEQUENCE 

• EVALUATE/ COORDINATE- USER EXPERIMENT REQUIREMENTS 

• SET-UP AND CALIBRATE SCIENTIFIC INSTRUMENTS 

■ • ACTIVATE/DEACTIVATE SCIENTIFIC INSTRUMENTS 

• COORDINATE EXPERIMENT SEQUENCE WITH USER 


• EXPERIMENT DATA .ANALYSIS 

• EVALUATE POC PROCESSED EXPERIMENT DATA 

• MONITOR RAW EXPERIMENT DATA QUALITY 

• PREPROCESS' EXPERIMENT DATA FOR USER QUICK-LOOK 

• EXPERIMENT STATUs’-.MONJTORING ' 

t ..'ANALYZE OUT-OF-TOLERANCE SUBSYSTEMS 
§ MONITOR/EVALUATE EXPERIMENT PERFORMANCE 

• MAINTAIN EXPERIMENT STATUS LOGS 


- teOMMON ' MEANS 'COMMON TO -ALL PAYLOAD.S .REGARDLESS- :.QF, C.LASS 



2,1.2.2o1,2 Unique POCC Functions 

Unique POCC functions with respect to each payload class were 
identified and grouped into similar subsets. An analysis of these 
subsets for any one of the payload classes shows that a unique function 
belongs to one of the following groupings: 

.a. Mission Planning 

b. Flight Support 

c. . Payload Operation and Control 

d. Experiment Operation and Control 

Moreover, each such unique function was highly dependent on the pay-, 
load type and the nature of the experiment. 

Unique functions for each of the three payload classes are listed 
in Tables 2,ltn through 2,lqo 

2.1„2.2,2 Summary of Functional Standardization 

From the foregoing analysis, we can make the following assumptfons 

. a. AllPOCC's designed to handle one class of payload can be 
highly standardized with only a limited set of unique func- 
tions strictly dependent on payload control arid scientific ■ 
experiment. 

b. It is possible to design POCC's capable of handling two or 
more payload classes. The extent of unique functions is, . 
however, higher than for (a) because of the greater extent 
■ of uniqueness' introduced by the basic differences ' between 
payload classes. For example, planetary payloads, and experi- 
ments are quite different from Spacelab or Automated Earth 
Orbiting Payloads. 
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TABLE 2.1m. GSFC UNIQUE PAYLOAD OPERATION CONTROL FUNCTIONS 

• EOS DELIVERY 

• COMPLETE 'PAYLOAD CHECKOUT FOLLOWING SEPARATION FROM ORB ITER 

t COMMAND PAYLOAD TO'THE SELF-BOOST CONFIGURATION FOR ORBIT 

• TRANSFER INITIATION 

• INITIATE PAYLOAD' ASCENT MANEUVER 

• HEAD RETRIEVAL 

• COMMAND RAYLOAD TO NORMAL OPERATION , . 

PLAN 'REACTIVATION OF' ATTITUDE' CONTROL AND DETERMINATION SUBSYSTEM (ACDS), 

• REACTIVATE ACDS FOR ORBITER RETRIEVAL ‘ ‘ 

• *PLAN' AND SUPPORT ORBITER, .RENDEZVOUS FUNCTIONS 

• *VERIFY/ MONITOR PAYLOAD SAFETY AND CONTAMINATION STATUS 

• *DETERMINE- EPHEMERIS' CORRECTION NEEDED FOR RENDEZVOUS 

• ■ *b.EFINE .AND£INPUT CORRECTIVE MANEUVERS AND ASSOCIATED COMMANDS 

FOR PAYLOAD,. AND ORBITER 1 ' . 

• *MONITOR DO.CKING MANEUVERS ' ' 

• ‘-*VERIFY-PAYL0AD/0PERATi0NAL STATUS PRIOR TO' ''RETRIEVAL 

• -*MONI.TOR PAYLOAD/ORIBTER CONFLICTS DURING' REENTRY 

• *INITIATE AND VERIFY PAYLOAD DEACTIVATION DURING DESCENT 

• *TRANSMIT SPECIAL HANDLING' INFORMATION ON PAYLOAD TO LANDING SitE V 

■? ^ , 

*THESE FUNCTIONS ARE UNIQUE TO THE PAYLOAD SERVICE/RETRIEVAL OPERATION, NOT TO THE PAYLOAD 
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TABLE 2.1m. GSFC UNIQUE PAYLOAD OPERATION CONTROL FUNCTIONS (CONTINUE) 


• EOS SERVICE 

• ^COMMAND PAYLOAD TRANSFER TO ORBITER ORBIT 

t *PERFORM ALL PAYLOAD/ORB ITER RENDEZVOUS AND DOCKING FUNCTIONS 
SIMILAR TO HEAD 

t INITIATE/MONITOR PAYLOAD MODULE EXCHANGE OPERATION/MECHANISM 

• *DETERMINE REPAIRS, REPLACEMENTS, CHANGES, ADJUSTMENTS AND . 

■ REPLENISHMENTS REQUIRED FOR PAYLOAD 

• *PLAN SERVICING PROCEDURE 

• *MONITOR NEW INSTALLED EQUIPMENT 

• ^PERFORM -PAYLOAD PRE-DEPLOYMENT CHECKOUT 

• *PERFORM ALL PAYLOAD DEPLOYMENT FUNCTIONS SIMILAR TO EOS DELIVERY 

• ST DELIVERY 

• **FUNCTIONS SIMILAR TO EOS DELIVERY 


* THESE FUNCTIONS ARE UNIQUE TO THE PAYLOAD SERVICE/RETRIEVAL, OPERATION, NOT TO THE PAYLOAD. 

** THESE FUNCTIONS ARE -UNIQUE 'tO 'THE DELI VERV/SERVICE OPERATION, NOf TO THE PAYLOAD'. 
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TABLE 2.1m. GSFC UNIQUE PAYLOAD OPERATION CONTROL FUNCTIONS (CONTINUED) 


ST SERVICE 

• **FUNCTIONS SIMILAR TO EOS SERVICE 

• **VERIFY PAYLOAD PLACED ON EXTERNAL POWER DURING PAYLOAD RETRIEVAL 

• • -**PLACE PAYLOAD ON INTERNAL POWER UPON COMPLETION OF SERVICE 

■ • DURING PAYLOAD DEPLOYMENT, ORIENT PAYLOAD FOR MAXIMUM SOLAR POWER 

AND DEPLOY SOLAR ARRAYS AND TDRS ANTENNAS 

• **PERFORM PAYLOAD POST- DEPLOYMENT CHECKOUT 


FFTO 

• MONITOR/CONTROL FFTO 'MANEUVERS 

' • -MONITOR/ CONTROL FFTO RENDEZVOUS PROCEDURE ‘ 


** THESE FUNCTIONS ARE UNIQUE TO THE DELIVERY/SERVICE OPERATION, NOT TO THE PAYLOAD 
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TABLE 2. In. GSFC EXPERIMENT DEPENDENT UNIQUE FUNCTIONS 


• EOS DELIVERY 

• UNCAGE/RECAGE TELEMETRY SCANNER 

• INITIATE REMOVAL OF PROTECTIVE COVERS AND CONTAMINATION SHROUDS 

• • OPERATE AND MONITOR TELEMETRY SCANNER FOR NORMAL OPERATION 
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TABLE 2.10. JSC UNIQUE PAYLOAD OPERATION CONTROL FUNCTIONS 

• ATL 

• ESTABLISH INITIAL PAYLOAD POINTING 

• COORDINATE SCHEDULE/LOCATION OF GROUND TRUTH DATA COLLECTION 

• MONITOR STS STATUS AND PERFORMANCE 

• ALLOCATE/MODIFY GROUND AND ONBOARD FUNCTIONS AS REQUIRED 

t AMPS 

• DIRECT PAYLOAD TO PERMIT SIMULTANEOUS OBSERVATION OF EARTH AND 
MAGNETOSPHERE 

• ESTABLISH INITIAL PAYLOAD POINTING 

• CONTROL SUBSATELLITE OPERATIONS 

0 SO 

• ALIGN PAYLOAD IN AN OPTIMUM DIRECTION RELATIVE TO THE SUN 

t SEOPS 

• ALLOCATE/MODIFY GROUND AND ONBOARD FUNCTIONS AS REQUIRED. 

• . HEA ■ 

• GROUND CONTROL OF ON-ORBIT OPERATIONS 
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TABLE 2.2p. JSC EXPERIMENT DEPENDENT UNIQUE FUNCTIONS' 


• ATL 

• CALCULATE EPHEMERIDES OF CELESTIAL BODIES FOR TELESCOPE SIGHTING 

• CALCULATE POINTING ANGLES FOR EARTH LOOKING INSTRUMENTS 

• MAINTAIN TEMPERATURE OF BIOLOGICAL REFRIGERATOR 

• PROVIDE TARGET SELECTION, TIMING AND POINTING ANGLES 

• MONITOR TESTS FOR COLONY GROWTH EXPERIMENTS 

• DEPLOY/ RETRACT BOOM 

• MONITOR ENVIRONMENTAL EFFECTS EXPERIMENT DATA 

§ VERIFY LIDAR MEASUREMENTS 

• MONITOR UV METEOR SPECTROSCOPY DATA 

• IN GENERAL, PERFORM REPETITIVE EXPERIMENT SET-UP, OPERATION, 
SHUTDOWN AND DATA EVALUATION 

• AMPS 


• ANALYZE PERIODICALLY COLLECTED DATA 

• COORDINATE GROUND BASED ANALYSIS WITH ELECTRON AND CHEMICAL 
INJECTION EVENTS 

• MONITOR TELESCOPE POINTING 

• EVALUATE TARGET POINTING DATA 
a MONITOR FILM USAGE 

a VERIFY GAIN SETTING AND EXPOSURE TIME 

a DEPLOY/ RETRACT BOOM 

a MONITOR SUBSATELIITE OPERATIONS 
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TABLE 2. Ip. JSC EXPERIMENT DEPENDENT UNIQUE FUNCTIONS (CONTINUED) 


SO 

• MONITOR -ANTENNA POINTING 

• 'provide TARGET POINTING AND TIMING DATA 
e ■ COLLECT TARGET GROUND TRUTH DATA 

• COORDINATE GROUND TARGET ACTIVATION 

• .MONITOR TERRESTRIAL WEATHER DATA 


« CONTROL/MONITOR MAGNETIC. SPECTROMETER 
LS 

• ' ASSESS' AND RECORD' EXPERIMENT DATA IN REAL TIME 
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TABLE 2.1 q. JPL UNIQUE PAYLOAD OPERATION CONTROL FUNCTIONS 


• MARINER 

• • CALCULATE TARGET-PLANET EMPHEMERIDES FOR USE IN SPACECRAFT TRAJECTORY* 

• CALCULATE AND ACTIVATE MID-COURSE CORRECTIONS 

• ACTIVATE/ VERIFY PAYLOAD ELECTRICAL POWER SYSTEM 

• *PERFORM QUICK-LOOK CHECK OF lUS/PAYLOAD 

• *MONITOR lUS/PAYLOAD DEPLOYMENT AND VERIFY SATISFACTORY 'DEPLOYMENT 

• COMMAND PAYLOAD TO SAFE-BOOST CONFIGURATION FOR TRANSFER ORBIT 

• 'REMOVE PROTECTIVE COVERS AND CONTAMINATION SHROUDS 
§ VERIFY I US/ PAYLOAD GO/NO-GO FOR INJECTION 

• VERIFY MARINER INJECTION SEQUENCE 

• ARM PAYLOAD PYROTECHNICS AND’ PRESSURIZE PROPULSION 

• 'ENABLE PAYLOAD PROPULSION MODULE 

• AT ENCOUNTER, CONTINUOUS REAL-TIME MONITORING AND PREPROCESSING OF- 
SCIENflFIC AND ENGINEERING DATA 

• TRANSMIT CORRECTIVE INPUTS TO ENGINEERING AND SCIENCE INSTRUMENTS 

• FOLLOWING TARGET ENCOUNTER PREPARE AND TRANSMIT DALLY FLIGHT' 

ACTIVITY SEQUENCE 

• '*MONITOR lUS/PAYLOAD FLIGHT CONTROL ACTIVITY 


• PIONEER’ 

• *MONITOR TUG/PAYLOAD FL-rGHi;, CONTROL ACTIVITY 


* THESE FUNCTIONS ARE UNIQUE TO THE lUS/TUG OR SSUS OPERATION, NOT TO THE PAYLOAD 



c. The optimum POCC will functionally consist of the set of 
common functions augmented by a set of unique required 
functions- depending on payload class and' experiment. The 
set of common functions are self-sufficient in the sense 
that they include all essential functions to coordinate-, 
execute and monitor all ' standard data processing, and 
system support functions-; they also include basic payload oper- 
ation and control' as well as standard experiment control func- 
tions. 

From, these results, we can introduce the concept of the Standard POCC 
(SPOCC) with its standard functional model. Figure 2.1-3 is a functional 
block diagram of a SPOCC showing: 

• All common functions 

• Functional areas where unique functions could be added- 

t Main interfaces - 

t Top level, data flew. ' 

Such a POCC model could be- used- at JSC', GSFC or JPL with the only 
difference being the extent of additional unique functions-. A SPOCC 
could be made to handle .any two" or even all three classes of payloads. 

It is also possible to. concep-tual ize the idea of a fu,lly standard 
POCC where software and- hardware capabilities exist to handle any class 
of payload. Functionally,, this- POCC would have a standard' resident set 
of' all the identified common functions while the specific set of unique 
functions would be.'added as required to pe^it total POCC reconfiguration, 
from one payload class to another.- • ‘ . 

The idea- of full functional s'tandardization allowing a POCC .the 
capability to handle any payload is not considered practical due to- high 
cost and inefficiency. Furthermore, the study guidelines dictate -the 
fol 1 owi-ng : ■- 
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Figure 2.1-3. Standard POCC Functional Block Diagram 















a. JSC POCC's initially handle Spacelab Payloads with future 
expansion to Automated Earth Orbit Payload activity. 

b. GSFC POCC's initially handle Automated Earth Orbit Payloads 
with possible future expansion to Spacelab Payload activity. 

c. JPL is exclusively assigned for Planetary Payloads. However, 
expansion to a capability to handle Spacelab and Automated 
Earth Orbit payloads on a backup basis is feasible. 

Therefore, it 4s safe to assume that both JSC and 6SFC should be -given , 
the capability of fully handling their primary payloads with additional 
capability (backup or degraded as a minimum) to handle their secondary 
payloads. As- for JPL, planetary payloads should normally be the only 
objective. An examination of the VARDLEY. Modified; Payload Traffic Model 
shows the high number of planned Spacelab and Automated Earth Orbiting 
Payloads compared to Planetary -Payloads suggesting .possible overload 
conditions for JSC and GSFC and the possible re.quirement of using JPL 
as a backup even to a limited extent, common functions only for example. 

Cost considerations emphasize the need for .'limited standardization 
using the concept of the Standard POCC as' illustrated by the simplified 
activity matrix on Figure 2,1-4, For both JSC and GSFC,. full backup 
capability is provided. In case of overload or even complete .failure,*, 
automatic switch-over, transparent to the' operator .al. lows' the -POCC of ) 
one Center to use totally or even par.tially software and; hardware' sub- 
systems residing at a POCC of the other Center. JPL can only provide 
.limited backup capability to both .GSFC and JSC (common functions only) 
and there are no plans to provide backup of Planetary POCC's for JPL. 
Note that full -backup capabtltty is proposed; between POCC's of the same 
Center. 

Figure 2.T-5 compares schematically the' functional characteristics 
of the three primary POCC's in terms of totally dedicated, full stan- 
dardization and limited standardization; The latter approach is the 
most optimum since it is less expensive -thdn the former two and yet 
provides the desirable primary and backup capabilities. 
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The common POCC, which includes .all common and standard support func- 
tions, is the same for all three POGC types. With adequate communica- 
tion, it would be easy to reconfigure, a Center to make full use of 
the common POCC of another. Automated- Earth Orbit (-AE0) and Spacelab 
unique functions -are made available to both- JSC and GSFC. ,Each primary 
set of unique functions is resident in its respective primary POCC; 
the other set of unique functions can be made available, upon request, 
through hardware reconfiguration and software loading (for both GSFC 
and JSC POCC's, this means that the available manpower should be familiar 
with both Spacelab and AEO Operational" procedures). Planetary unique 
functions are. exclusively allocated to JPL. 

The concept of functional standardization is also applicable to ■ 
remote portable POCC's' allowing other NASA Centers or User Facilities 
to operate as on-line secondary payload control centers. Remote por- 
table POCC's are specially suited to handle overloads from these 
Centers. 

Functional standardization allows a POCC to standard.! ze its. pro- 
cessing hardware... Since a large percentage of POCC functions are com- 
mon to all classes of payloads, the baseline hardware can -also be 
assumed standard. The standard POCC hardware should .have enough spare 
capability (CPU memory size, processing power, mass storage, peripheral's) 
to accommodate all the required unique functions. .A distributed archi- 
tecture i's .recoiraiended for the standard POCC with all functions alloca- 
ted to an array of mini processors. Figure 2,1-6 depicts a typical 
standard POCC architecture; functions allocated to each processor are 
clearly indicated; the diagram also shows all ex-ternal interfaces, 
required peripherals and the’ estimated processing power of each mini 
in terms of instructions per second. ■ ' ' ' 

Standardization can also be- extended to software packages. 

Standard software routines common to all POCC's are assumed resident in 
main memory, while unique software packages are stored in mass storage 
and loaded to main memory when required by the data processing operating 
system. Standard methods could be devised to design, develop 'and main- 
tain this software with a standard set of diagnostic routines for check- 
ing and validation. 
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Figure 2.1-6. Standard POCC Hardware Architecture 







2J.2.2.-3 Advantages of Functional Standardization 

Compared to totally dedicated, specially designed and developed 
POCC's to handle unique experiments, standardization offers an alterna- 
tive in line with the basic characteristic of the Space Shuttle era, 
namely, reuseability at a minimal additional cost. Initial costs 
required in the design and development of the Standard POCC need not 
be higher than the aggregate of the various Centers* costs to upgrade 
their POCC equipment and software in accordance with the changing tech- 
nology. Furthermore, overall life cycle costs should be greatly re- 
duced. Table 2.1r lists advantages and disadvantages of .standardization. 
Cost savings is by far the greatest advantage. 

2. 1.2. 2.4 Standard POCC (SPOCC) Network 

The SPOCC concept is recommended as the basis for a cost effec- 
tive NASA-wide network of Payload Operation Control Centers configured 
to handle the maximum traffic loads to be experienced in the STS era. 

The three basic centers, namely JSC, GSFC and JPL, are each used for the 
primary control of their class of payloads. Each Payload Operations 
Center (POC), communicates with a number of SPOCC 's each capable of 
handling any assigned STS payload during the joint operation and 
selected ones capable of handling free flyer operations. All SPOCC s 
are on-line with the corresponding POC. All three Centers communicate 
with each other directly. The Integrated Operations Manager (lOM) 
becomes involved when necessary to resolve conflicts or make decisions 
affecting more than .one Center. JSC and GSFC SPOCC 's can be reconfigured 
to handle either Spacelab or AEO payloads, while JPL SPOCC 's are ex- 
clusively limited to Planetary. Any SPOCC of a Center can use any one - 
of the others as a backup through direct communication; any JSC SPOCC 
can provide full backup capability for a GSFC SPOCC and vice versa; any 
JPL SPOCC can provide limited backup for either- a JSC or GSFC SPOCC. 

A SPOCC may simultaneously support the combined STS operation of a 
Spacelab or AEO payload and a free flyer operation which is independent 
of the STS. Each SPOCC has its own local. data base which is independent 
of the Center's "data base. Individual SPOCC data is made available to 
any other SPOCC in the network through direct communication via the lOM. 
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The Integrated Operations Manager (lOM) data base keeps track of the 
interaction between SPOCC's of different Centers and keeps a record of 
all interface data. 

Figure 2,1-7 describes the baseline NASA network of Standard POCC's. 
In addition to the prime Centers and their SPOCC's, the figure shows 
the main external interfaces. STDN, TDRSS and DSN are placed under a 
common Network Operation Control Center (NOCC) whose function is to 
perform all support functions of tracking and data acquisition resources 
by a single responsible authority. The MCC is directly connected to 
the lOM, the NOCC and the KSC/VAFB. Standard remote portable SPOCC's 
are allowed to operate with each host POC via DOMSAT links. All POCC's 
of a Center can communicate directly with each other under control of 
the POC. POCC's of different Centers are allowed to communicate under 
control of NASCOM operations. 

The concepts of limited SPOCC standardization and limited backup 
capability within the SPOCC system offer an optimum low cost system 
that permits efficient pooling of resources and eliminates unnecessary 
redundancies. Although using a standard configuration, each Center's 
SPOCC is allowed to retain its primary payload characteristics with an 
option for reconfiguration to a secondary mission when required. 
Standardization at a system level allows for low cost software and hard- 
ware maintenance, reduces manpower training time and simplifies command, 
control and communication requirements. 

2. 1.2. 3 Implementation Activity Network 

This section will outline the implementation plans recommended for 
achieving the NASA-wide system of standard STS/Payload POCC's. The con- 
cept of Standard POCC (SPOCC) described in Section 2. 1.2. 2 will be the 
basis for the proposed approach. 

2. 1.2. 3.1 System Characteristics 

The major system features with respect to standardization are: 

a. Limited standardization is recommended where each of the three 
primary NASA Centers are primarily responsible in handling their 
own payloads, namely: 
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1. JSC has primary responsibil-i ty for Space Tab payloads. 

2'. GSFC has. primary responsibility for-AEO payloads. 

3. JPL has^ primary responsibility for Planetary payloads. 

In addition, it is recommended that provisions be made for GSFC to pro- 
vide full backup capability for Spacelab payloads, and -JSC to provide 
full backup capability for AEO payloads. Under this plan, JPL could 
only prov.ide limited backup capability for both GSFC and JSC. No back- 
up is recommended at other Centers for JPL payloads. 

b. Except for a set of unique POCC functions depending exclusively 
on payload operation and experiment contVol , all remaining 
functional requirements are found to be common to all POCC's. 

This functional commonality is, the basis for POCC software and 
eventual .hardware standardization. 

c. The Standard POCC network depicted in Figure 2.1-7 provides 
the baseline configuration. Necessary communication is pro- 
vided to allow full backup capability between SPOCC's of the 

' same Center and limited backup capability, as described previously,' 

. . between SPOCC's of different Centers. A common Network Operation 
, ' (Control Center is recommended to handle all data. Each Center 
utilizes a payload coordinator (PC) .and the Integrated Operations 
Manager controls the interface between Centers. The remote por- 
table Standard POCC allows a remote user to communicate with 
the system and conduct experiments at his facility. 

2.1„2.3,2 Drivers for System Implementation 

The major drivers for system implementation are: 

a. Cost is the major driver and dictates the pace of system evo- 
lution. A cost-effective approach to standardization requires 
that the change-over of each system element to a standard 
implementation occurs at the time nominally planned for moderniz- 
ing or expanding existing equipment, software and procedures. 

b. Existing long-range plans of each participating Center will 
influence the time table for making system changes. The 
various Centers' plans should be reviewed to determine methods 
of converging toward common SPOCC system architecture’ whil e 

at the same time enhancing the Centers' POCC capabilities at the 
pace required to support the increase in STS payload activ.ity 
supported by each Center. 
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c. The Spacelab POCC.'s. will become drivers for the standardiza- 

tion of design. Since Spacelab POCC's for the Mature Operation 
al Phase of STS do not exist as- such, .early efforts should be 
devoted to ensuring' that any new resources acquired' for these 
POCC's will contribute to long-range plans for standardization 
of SPOCC architecture. . , 

d. Another driver is. the bui'ldup of communications traffic, .As 
the load builds with an increase .in launch frequency and multi- 
ple overlaps of long duration operations, network enhancements 
to meet these requirements should support standardization of 
system interfaces with POCC.'s, including methods of in'terfacing 
remote portable POCC's. 

e. As industrial applications for STS payloads are developed in- 
number, the need for simplified standard methods of supporting 
a wide range of users in their own facilities will become 
apparent. The remote portable POCC, standard methods of inter- 
facing various communications networks and methods of standard 
data .processing support will be essential prior to .wide accep- 
tance of the STS system by industrial users,. 

, ) 

f. 'Introduction of the Payload Coordinator (PC) .function at each 
Center and the Integrated Operations Manager (lOM) Into the 
Payload Command and Control hierarchy will also dic.tate the 
necessity for standard POCC architecture and procedures. 

g. Imposition of standards for NASA and DOD payloads and' the 
introduction of the Multimissi'on Modular Spacecraft will lend 
further impetus to standardize the ground support resources. 

2. 1.2. 3, 3 Implementation Plan and Schedules 

Figure 2.1-8 describes a summary of the development activity net- 
work with- timeline and interactions between activity blocks. A brief 
description of the activities of each block will be given next. 

2. 1.2. 3. 3.1 1977-1978 Activities 

The major thrust of the recommended POCC implementation plan is to 
reduce ground operating costs through an evolutionary implementation of 
flexible standard systems of hardware .and software for POCC's to be 
implemented- as replacements. 'at the time of the normal equipment genera- 
tion update period. 
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Figure 2.1-8. SPOCC System Develop- 
ment Activity network 
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Over the past decade, the NASA Centers with responsibility for 
Payload Operations have developed sophisticated capabilities for com- 
mand and control of their assigned types of payloads and, in recent years, 
planning at these Centers has included considerations for standardization 
among the POCC's employed at these Centers- This study subtask has 
assessed the feasibility of extending POCC standardization to include 
payloads of different types. 

It is not feasible or cost effective to discard existing systems 
in the interest of standardization. What the study -recommends- is an 
evolutionary approach .based on a modular system architecture which 
can be implemented incrementally as existing systems become obsolete 
or require augmentation due to increased system loads. 

Two initial tasks are scheduled during this period. They are: 

a. The detailed definition of requirements in terms of hardware, 
software and procedures based on the concepts set forth in' 
this task. 

b. The all important task of conducting cost analyses and trade- 
offs to drive the implementation planning to the least cost 
solution and to show quantitatively the savings to be gained 
as a result of a standard NASA-wide system of SPOCC's. 

During this timeframe, a variety of tradeoff tasks, and require- 
ments analysis tasks are performed including: 

t Detailed requirements definition for computation resources, 
man-machine interfaces, communications system enhancements, 
consolidation of data base system- requirements , definition 
of the Data Processing Operating System, facility requirements 
and configurations for portable POCC's. 

• Cost analysis and tradeoffs include assessment of cost savings 
resulting from integration of network control for STDN, TDRSS, 
and DSN; costs of implementing a standard design for Remote 
Portable POCC's; cost savings resulting from implementation 
of the Payload Coordinator (PC) and the Integrated Operations 
Manager (lOM); and cost trades considering various methods 
and timeframes for implementing the SPOCC's, 

• A change policy for users of standard portable POCC's must be 
defi ned. 
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Following the cost analysis and requirements definition tasks, 
a detailed implementation plan .must be generated. . In. this activ.ity, 

1-t win -be necessary to review the long-range .plans of each Center ' 
and integrate the individual • Centers plans into a NASA-wide master 
plan in, order to converge toward a standard approachi to POCC Implemen- 
tation. • • • . - ' 

As an example of this planning activity, the replacement scheduTe 
for computers, for each of the three Centers, should be, coordinated such 
that future data processing tasks can be modularized -in a standard 
system design with similar functions for each Center allocated. -to sim- 
ilar hardware which, in turn, should be sized for the largest, requirement 
if Centers are to provide backup services, for each' other, at a- future- 
date. 


Implementation planning will involve detailed scheduling and • 
activity networks required to phase-in the' standard POCC's -ovef the 
ensuing 3-1/2 years. 

•Other major considerations will include: 

• -System baselining and maintenance, of configuration control 
through the evolutionary period. 

e Coordination of plans between the Centers to effect economics. - 
during procurement of system elements, and to .ensure common 
design approaches where feasible. 

•. - Detailed schedules will be developed ‘.for each Center's acti- 
vities over the full time period until mid-1982. An overall 
•system schedule will be required to coordinate- the detailed 
Center schedules. 

- • Detailed planning of the PC and lOM functions will be required 
so that :sys tern design can reflect efficient man-machine inter- 
faces to incorporate. these. functions in- the design of future 
.generation consoles,-.display systems ahd.data handling systems. 

2. 1.2. 3. 3, 2 Activities from 1979 through Mtd-1982 . 

As shown in Figure 2.1-8, there are several activities which pro- 
ceed In parallel during this' period.' ‘ 
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Initial Spacelab POCC Implementation must start in time to provide 
a modest capability for the early Spacelab flights. Since these POCC's 
do notexist except as capabilities left over from Apollo, Skylab, and 
Apollo-Soyuz Programs, early efforts will probably focus on methods, 
to employ these resources for the initial support of JSC Spacelab POCC's. 

As the flight rate and level of complexity of Spacelab flights 
start to build up beginning in about mid-1980, the development of a 
final architecture for Spacelab POCC's should evolve. This embraces 
the proper timeframe for coordination of the standard POCC design among 
the Centers so that the configuration of the standard POCC can evolve 
along practically the same timeline. 

GSFC and JPL POCC's will be in a more mature stage of development 
than Spacelab POCC's and, therefore, should start the phase-over 
to standardization at an earlier date, beginning in 1980 since changes 
will impact them more. 

At the bottom of Figure 2,1-8, are shown the time phasing for var- 
ious elements of individual POCC standardization, as well as system 
implementation involving the networks, communications and the super- 
vising data base management system. It will be noted that these activities 
overlap each other but are shown in a logical sequence. 

The implementation of system communication standards, and super- 
visory data base management system will likely precede the standard 
data processing system and the Data Processing Operating System since 
they can function in a degraded mode until the Data Processing System 
can incorporate all of the system enhancements which are inherent in 
these standard systems. 

While the Data Processing System and its software may occur slightly 
ahead of implementing standard consoles, display systems and other 
man-machine interface hardware it would be beneficial if they evolve 
together. 
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The design of all system elements must take .cogni zance^- of the re.- 
quirefnents which wilt have been previously established /for' -the. PC -s \- 
and the- IOM so that console positions, commiini cation station’s, displays 
and other considerations will have been included even though 'the- intro- 
duction into the STS Payload Operations of these functions may hot come 

; l » 

until 1982 or later. 

One of the last features of the integrated network of NASA-wide 
■POCC's to be implemented will be the capability of one Center to back-up 
certain functions of another Center! this feature will not be^needed ‘ 
until the traffic load approaches saturation for a given Center. Fur-'.. 
thermore it can not be implemented- effectively’ until DOMSAT communica- 
tions can be made available economically to transfer high rate data from 
one POC to another. When the communications system is available.it - 
will, for example, be feasible for one Center to off-load some of the 
computing load of another Center by direct computer- to -computer trans- 
fer of jobs. 

The implementation of remote portable POCC's for use "in interfacing 
industrial and other users with the NASA operational system from their - 
industrial facilities will be required as the STS becomes aj recognized 
mode of space transportation. The capability to interface Remote .••• 
Portable POCC's with JSC, GSFC and JPL in that order should be implemente 
into the system of Standard POCC's. If the requirements study shows 
the need for remote POCC's at a later time in the STS operational era, 
the implementation of the Remote POCC's could then be introduced with 
minimum impact on the SPOCC Network. 
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2,1.3 Subtask 2A Summary Conclusions and Recommendations 


(1) The Standard POCC (SPOCC) is recommended for use during joint 
STS-Payload operational phases. In the case of large, complex, 
automated satellites, the continuing free-flight operations 
would be controlled from the payload-unique portion of the POCC, 
supported from time- to- time by a SPOCC when service missions, 
retrieval or back-up support are applicable. 

(2) The SPOCC concept should be implemented and ready for support 
of payloads by the time the payload traffic model reaches 

50 percent of the maximum level, which is mid-1982, 

(3) The implementation of the SPOCC should evolve through augmenta- 
tion of existing POCC systems and grow toward standardization as 
present systems are phased out due to obsolescence. 

(4) As existing large-scale computers become obsolete, their replace 
ments should be with minicomputers or modular components which 
can be dedicated to specific functions or sets of functions. 
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•2.2 DETAIL OPERATIONAL INTERFACES BETWEEN STS OPERATOR AND PAYLOAD 
OPERATOR FOR PRELAUNCH AND, FLIGHT PHASES {SUBTASK 2B) - 

2.2.1 Introduction 


This subtask will detail and refine the implementation guidelines for 
the three NASA-approyed flight control concepts for STS payloads in addi- 
tion to DOD payloads with emphasis on operational interfaces with STS Flight 
Operation. Interface philosophy for both prelaunch and operational phases 
are established as follows: 

• STS Payload Opera to r-*HMCC-H (including DOD) 

• STS Payload Opera tor-*-*-KSC 

• STS Payload Operate r-^VAFB 

• STS Payload Operator/STS Flight Operator - NASA Networks 

2. 2, 1,1 Study Guidelines for Subtask 2B 

The general study guidelines for the performance of Subtask 2B excerpted 
from the Study Plan are: 

1. The STS, consisting of the Shuttle, lUS/SSUS and Spkel'ab support 
systems, with flight control from MCC/JSC, provides a service to 
"customers." ["Customers" here are all NASA Centers and selected 
non-NASA/non-DOD payloads that utilize NASA Centers for flight 
operations.] 

2. The main thrust of this study effort will address STS payload 
programs during the operational STS phase. 

3. Payload operations will be performed by a payload organization or 
its agent within safety limits established by the STS Flight 
Operator. 

4. MCC/JSC will provide "flight support’! for all NASA mission's during 
prelaunch, ascent, reentry and landing. ["Flight Support" here 
includes: 

GO/ NO-GO for launch 

Trajectory, Event Systems, Crew Status 

Landing site readiness.] 
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5. For on-orbit operations during pei^iods. when STS has .an.' operational 
interface with the payload, "flight support"' wiTT be jointly 
provided by MCC/JSC and the responsible Payload Operations.Genter.- 
[" Flight Support" here includes aii functions (tasksKdone in- • 
support of the on-orbit operations.] 

6. For on-orbit operations during periods when the STS has ,no opera- 

tional interface with' the payload, "flight support" will 4e • • ■ 
provided by the responsible Payload Operations Center or Agent . 
designated by the responsible. payload Project Office. . . ■ 

7. Payload organizations will utilize NASA Control Center' host- 
facilities for operations or establish their own Payload Operations 
Centers where economically justified. ' . 

8. Major NASA Control Centers shall provide host facilities for 
customers, or provide appropriate operational interfaces -with 
customers' remote location with respect to the Control Center, if 
feasible. 

1 

9. Required voice, data, command- and tracking channels wiTT be- -■ 
provided to all operations areas, but coordinated by MCC/JSC so - 
long as- STS has an operat-ional interface. 

10. Simplicity of interfaces during launch/landing and during flight 
among, user,, developer and -operator, and ease of total STS/STS 
payload ground, system verification shall be considered as 
criteria, in assessing interfaces and costs. 

11. Emphasis will be placed on defining joint STS/Pay-load functions 
and flight phases rather than free-flight activities or mission 
operational activities involving only the payload.. 

2. 2, 1,2 Approach 

The approach taken' for the performance of Subtask 2B involves: 1) the 

assimilation of the basic study results with respect to the operational 
interfaces;. 2). development of POCC/Payload end-to-end communications. flow 
diagrams; and 3) descriptions of the communications flows for 'Payload 
Commands, Payloads Health Telemetry, and Payloads Science Telemetry. The 
criteria utilized during the establishment of the end-to-end flow diagrams 
were: 

1. Simplification of System Operation 

2. Standardization of Operating Procedures and Functions 

3. Maximum utilization of existing and planned capabilities 
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Subtask 2B output goals achieved were: 

1. Provide in one document the description >of all payload interfaces 
to facilitate further assessment and optimization of the opera- 
tional interfaces. if and where re,quired. 

2. Assess specific interfaces for possible simplification and/or 
standardization. 

3. Formulate and present study conclusions and recommendations. 

2. 2. 1,3 Scope 

This report will- describe POCC- interfaces in terms of prelaunch and 
operational phases. Sections 2.2.2 and 2.2.3, respectively. The interface 
descriptions in each section have been separated into Command' and Telemetry 
links. The Telemetry links are further discussed" in terms of Payload 
Health and Experiment Telemetry - data downlink transmission. The commands 
are described in terms of .payload command uplink transmission. Figure 2.2-1 
identifies the communications flow diagrams detailed in this report in 
terms of operations phases {prelaunch and operational), payload links 
(command or telemetry), and link types (Health or Science Telemetry) for 
each Payload Operations Center (JSG, GSFC, JPL, and DOD). The numbers 
within the blocks serve to: 

1. Identify the figures within this report where specific interfaces 
are illustrated. 

2. Identify which interfaces will be required for specific types of 
payloads. 

The performance of this study task relied heavily on operations 
information from several payload organizations.. 'Information included in 
this report was obtained either verbally or by reference to technical 
operations planning reports and presentations. Information acquired in 
the performance of this task may have been used directly within this 
report without alteration. TRW, therefore, wishes to, acknowledge the 
sources of data utilized in the performance of this task by identifying 
technical contacts and references in Appendix B of this report. 
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PHASE 

PAYLOAD 

LINK 

TYPE 

PAYLOAD ORGANIZATIONS/REPORT REFERENCE Figure 

JSC 

GSFC 

JPL 

DOD 

PRELAUNCH 

COMMAND 

2,2-2 

2.2-3 

2.2-4 

2.2-5 

TELEMETRY 

HEALTH 

2.2-6 

2.2-7 

2.2-8 

2.2-9 . 

EXPERIMENT 

2.2-10 

2.2-11 

(VAFB) 

2.2-12 

2.2-13 

2.2-14 

OPERATIONAL 

COMMAND 

2.2-15 

2.2-16 

2.2-17 ' 

2.2-18 

TELEMETRY 

HEALTH 

2.2-19 

2.2-20 

2.2-21 

2.2-22 

EXPERIMENT . 

2.2-23 

2.2-24 

2.2-25 

2.2-26 


NOTES: 


1) Numbers i^n blocks refer to figure numbers. 

2) All interfaces based on KSC except 2,2-11 which is VAFB. 

Figure 2.2-1. Summary of Figures Depict'ing Interfaces with POCC's, Prelaunch and Operational 




1 , 1.1 Prelaunch Activities 


2. 2. 2.1 General 

Prelaunch activities for this study phase include those payload opera- 
tions for Payload Commands, Payload Health Telemetry, and Payload Science 
Telemetry for JSC, GSFC, JPL, and DOD payloads during payload checkout and 
buildup of the Orbiter at the launch pad. 

2. 2. 2.2 Command Interface 

2. 2. 2. 2.1 JSC Payload Command Interface, Prelaunch Phase, KSC (Figure 2.2-2) 

The Spacelab and Spacelab payload sequence of operations are 
described in order to clarify the payload command interface requirements 
during the prelaunch phase. The operational sequence is presently envi- 
sioned as follows: 

a. After Orbiter landing, Spacelab is moved to Operations and Check- 
out Building [Payload Processing Facility (PPF)] where it under- 
goes postflight test and checkout for two to three days. The 
Spacelab experimental equipment is also separated in the PPF. 

b. Spacelab is subsequently placed in the Payload Checkout Stand 
(PCS) where it undergoes maintenance and refurbishment before the 
next flight. Commands are sent to the Spacelab and its payloads 
(and integrated payloads) from the Payload Control Room at KSC. 

The PCS provides for physical and functional simulation of the 
Orbiter interfaces. This simulation permits functional checks of 
Spacelab subsystems and payloads. 

c. The Spacelab is removed from the PCS and transported to the 
Orbiter Processing Facility (OPF) (or Pad) where it is installed 
in the Orbiter. Subsequent to the Spacelab and its payload having 
been integrated with the Orbiter, all further remote control and 
monitoring of the Spacelab is performed from the Orbiter and/or 
IPS. The Spacelab checkout is performed from the Launch 
Processing System (LPS) payload station console located in the 
Launch Control Center (LCC) (see Figure 2.2-2). 

Integrated testing of the Spacelab at the Pad is limited to those 
functions required to monitor the Spacelab- subsystems and the payload for 
launch readiness and to perform minimal preparations of the Spacelab for 
■ launch. 

The T = 0 umbilical is not used for Spacelab since there are no payload 
functions on it. Commands to the Spacelab are transmitted over the Orbiter 
Multiplexer-Demultiplexer (MDM) (see Figure 2,2-2). 
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The command data flow to the Spacelab while- in the PCS is from the 
PPF at KSC (Figure 2o2,-2). Command validation messages are retransmitted 
from the Spacelab. Command Data Buffer to the. PPF from where the command 
messages are. executed., When the Spacelab is on the Pad,' commands are 
transmitted to It .and its payloads from. the. Payload Station Console in the 
LCC. For end-to-end chepkout, commands are also generated at the JSC POCC 
in NASCOM. format and packed into NASCOM blocks for transmission via MCC-H 
over NASCOM links either directly or via the TDRSS ground station, over 
TORS, to MILA. Command data is subsequently routed from MILA to the 
drbiter and Spacelab, on the Pad, as shown in Figure 2.2-2, 

All commands issued by.JSC-POCC are stored' in the Orbiter computers 
and the commands are returned to the HCC-H for confirmation. The MCC-H 
then transmits a confirmation message back to the POCC.' Receipt of this 
positive confirmation message permits the POCC to transmit a "Command 
Execute" command. , ■ • • : ■ . 

Receipt of the "Command' Execute" causes the Orbiter computer to 
transfer- its stored commands to Spacelab and/or payloads. 

, This added precaution provides for extended crew safety and Orbiter 
protection. . ... 

2, 2. 2. 2, 2 GSFC Payload Commands Interface, Prelaunch Phase, KSC (Figure 2.2-3) 

2. 2, 2. 2, 2.1 Payload Arrival 

This concept is predicated on the assumption that the payload will 
have been thoroughly tested and evaluated at the payload contractor's ' 
facility or at an appropriate Government Facility prior to shipment to the 
launch site. Upon arrival of the'payload at the launch site, it is trans- 
ferred to the Payload Processing Fac.tlity (PPF), where it will be checked 
out with' the Ground Test -Equipment (GTE) which is comprised of a-Payload 
Ground Station (PGS), a Remote Payload Station (PS) Console, and a Payload 
Stimulus Console. 

Tests w.ili be conducted at the PPF to verify safe payload arrival at 
the launch site. 
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2. 2. 2. 2. 2. 2 Payload Installation 

Payloads may be either pad-installed or pre-pad-installed, .which- 
requires a s.light difference in operations at KSCl For example, a pre-pad- 
installed payload permits the performance of a more detailed'payload- cfieclc- 
out than would be possible if it was pad- ins tailed. A pre-pad-installed ‘ 
payload also will require a payload stimulus console to provide detector ■ 
stimulus and/or control signals. 

A pad-installed payload would be provisioned with- detector stimulus 
and control signals by virtue of its connectivity to the Orbiter. However, 
for mission-unique payloads, direct connections to the payload may-not-be ' 
allowed after payload installation in the Orbiter. 

2. 2. 2. 2. 2. 3 Interface Testing 

Payload preinstallation testing at KSC will be conducted in a .closed 
loop between the payload and the payload GTE as the focal point of tests 
operations as shown in the flow diagram. Figure 2.2-3. Tests will be con- 
ducted in the PPF to verify safe payload arrival at the launch site. The 
POCC will require data links to support commands and data flow and to 
verify communication links from KSC to GSFC. These links will be required 
to support POCC activities later in the payload flow. All the-links 
envisioned as necessary to support the payload activity are given in 
Table 2.2-1 . 

Prior to moving the payload from the PPF to the Orbiter Processing 
Facility (OPF) or the Payload Changequt Room (PCR) for installation in the 
Orbiter, a POCC-PGS-payload interface verification check will be made to 
ensure POCC ability to command the payload. 

It is planned that testing with the RF links will be performed in. 
conjunction with the. Orbiter avionics while the . payload is still in the 
PPF and the Orbiter is in the OPF. The MCC-H will be required to be on-line 
to receive and interleave a 2-kbps payload-command bit-stream from the GSFC- 
POCC and transmit it to the Orbiter in the OPF via MILA and MCC-H. The 
Orbiter will relay the payload 2-kbps portion of the interleaved command 
bit-stream to the payload in the PPF. 


2-64 



^ 0 ' 








\ 


f-RAME a_ 


'H 


POCC 

COMMAND GENERATOR 
1 43 BITS 
k 2 KBPS 

j • HLADEK ADDtESS - 
DJSmNJTION 
I • STANDARD NASCOM 
FORMAT 

I • CMO VALIDATION I. 
REMOTE POCC 


TELEMETFl' COMMAND 
VERIFICATION 
PROCESSING 


COMMAND 

VERIFICATION 



1 COMMANDS 

1 

1 


1 

n 

PAYLOAD 


REMOTE POCC 


Figure 2.2-3. GSFC Payload Command 
Interface, Prelaunch 
Phase, KSC 

2-65 














Table 2,2-1, Information Links, Command Interface, Prelaunch 
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Just prior to moving to the OPF^ tHe'^onb'oard computer in the command 
and data handling portion of the payload will be loaded with the flight 
program (or verified if the program has been previously loaded). Once the 
memory is loaded and verified at the PPF, it is not anticipated that any 
further memory loads will be necessary. However, the memory will be dumped 
and verified at least one additional time prior to launch. After the pay- 
load arrives at the OPF and is installed in the Orbiter, the GTE (PGS) will 
monitor payload commands as available via the T = 0 umbilical. The POCC 
will also be able to monitor the payload .commands either directly via the 
PGS through NASCOM or via the Orbiter 01 link. The PGS will command directly 
via the T = 0 umbilical and the POCC can command either directly or via the 
Orbiter avionics. . 

After payload installation and completion of interface testing, further 
monitoring will be done by both the PGS and the POCC. Payload data flow 
will be the same at the pad as it was for OPF-installed payloads. It is 
anticipated that all critical payload/Orbiter interface testing will be 
verified prior to arriving at the launch pad for payloads installed in the 
OPF. For pad-installed payloads, interface testing will be performed imme- 
diately following installation. Most of the launch pad' activity after 
installation and prior to the terminal count should consist mainly of 
payload monitoring. 

After the payload is installed in the Orbiter at the OPF or at the pad, 
it is a requirement to check out the payload- to- Ku-band interface if such a 
communications system is aboard the payload. This is to be an end-to-end 
test for transmission of payload commands and receipt of telemetry between 
the POCC, MCC, GSTDN, TDRSS, Orbiter, and payload. The PGS will process 
the demodulated Ku-band data to assist the interface verification. 

After the payload is installed in the Orbiter at the OPF or' at the 
pad, the POCC software will verify the hardline connection for commands 
through the Orbiter avionics system. 
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2. 2. 2. 2. 2. 4 KSC Interface Activity 

The payload will employ the. Flight Support System (FSS) to interface 
with the Orbiter. The FSS will bridge the standa'rd Orbiter interface -with 
the standard interface of the payload. The major components will be reten- 
tion trunnions, positioning platform, payload station panel, power condi- 
tioner, and associated cabling; A special purpose manipulator system (SPMS) 
and module exchange mechanism (MEM) will be added for a servicing mission. 

The interface verification equipment (IVE) will be used to verify the 
mechanical and electrical interfaces of the FSS-payload to those of the 
Orbiter prior to on-line operations (installation to the Orbiter). Typical 
examples would be verifying the Orbiter accommodations to support payloads 
using the same interfaces (use of an integrated cargo harness) and verifi- 
cation of non-interference between payload-to-payload interfaces (RFI, EMI, 
etc.),-' The performance of these verifications at KSC wi IT require- payload 
command, telemetry, and voice lines between the LVE facility and the PGS 
in the PPF. 

2. 2, 2, 2, 3 JPL Payload Command Interface, Prelauhch Phase, KSC (Figure 2.2-4) 

2.2. 2. 2. 3.1 Payload Arrival 

JPL payloads arriving at KSC are brought to the Payload Assembly and 
Checkout Facility (Building AO) prior to mating with the lUS. The payload 
is then transferred to the Sterilization, Assembly, and Encapsulation 
Facility (SAEF) where the payload will be mated to the lUS following the 
performance of a hierarchy of tests and operations. 

It is presumed that a Shuttle Orbiter simulator will be available to 
support the prelaunch tests in the SAEF such as: 

1. Verification and system testing of the payload-IUS-Orbiter 
interface 

2. End-to-end Data System capabilities. 

2.2.20203.2 Payload Installation ’ • 

Integration of the spacecraft with the I US and the Orbi-ter may be 
accomplished as a horizontal installation of the cargo into the Orbiter in 
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the Orbiter Processing Facility (OPF) or a vertical installation of the 
cargo (or payload) into the Orbiter on the' 1 abnch' pad. 

■ The primary -reasons for preferring- a cargo installation at the launch 
pad are: 

'1. It represents the shortest on-pad time. 

2. The availability of a. continuously controlled and monitored 
environment. 

2, 2. 2. 2. 3. 3 Interface Testing 

The operations concept for interface testing of the payload commands .. 
at KSC is shown in Figure 2.2-4, This operations concept assumes that pre- 
liminary testing of the payload at the subsystem and. system, level will, hav.e 
been completed; that the payload/IUS interface compatibility will have been 
tested; and that the payload end-to-end data system and' the STS .Data 
System mission-dependent elements will have both been tested and- verified. 

Upon completion' of the payload/IUS integration and verification of ’'the 
payload/IUS and cargo/Orbiter interfaces, a payload/STS end-to-end Data ' ' 
System compatibility test will be performed. This test will provide 
verification that the JPL POCC can command the payload. 

Remote monitoring and control of the payload at the launch pad will be 
retained in Building AO via landlines to payload GSE installed in the MLP 
and then to the payload via hardlines to the T = 0 umbilical. Verifica-- 
tion of command reception is also provided by an S-band link between the 
payload and Building AO via the T = 0 umbilical and launch pad/AO link. 

S-band and X-band link verification is performed with the cargo doors 
open and the RF signals are reradiated between the launch pad MLP and. 
MIL-71. 

The flow of commands are generated at JPL POCC and are- transferred to 
the payload via several different. paths. 

1. JPL POCC generated commands are tra.nsf erred to MCC-H via NASCOM. 
where the validity of all Orbiter associated Commands are con- 
firmed. The commands are then transferred vi,a NASCOM to the 
TDRSS which in turn communicates with MILA-GStDN via KSA or SSA 
band. The MILA then relays the command to- the Orbiter via. the,. . 
ground support equipment (GSE) of the MLP. 
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Figure 2.2-4. JPL Payload Comnand 
Interface, Prelaunch 
Phase, KSC 
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2. JPL POCC generated commands are transferred to MCC-H via NASCOM 
where the validity of all Orbiter associated commands are con- 
firmed. The commands are then transferred via NASCOM to MILA 
GSTDN and thence to the Orbiter via the GSE of the MLP. Upon 
receipt, validation, and distribution of the command, a command 
response is generated and is returned to the JPL POCC via the 
return path (MCP-MILA-NASCOM-MCC-H-NASCOM-JPL POCC). 


Command verification is acquired by processing the payload telemetry 
which will have been stripped from the payload-IUS-Orbiter telemetry data 
stream by MCC-H. 

2. 2, 2. 2. 4 DOD Payload Command Interface, Prelaunch Phase, KSC (Figure 2.2-5) 


■ Prelaunch communications are designed to provide DOD payload integra- 
tion and checkout and range safety. The communications flow is shown in 
Figure 2.2-5. The communications requirements are based on the evaluation 
of the KSC systems description, available Ground Operations System material, 
and DOD Mission Operations System Segment Communications and Tracking 
Requi rements Descri pti on . 


DOD payload checkout prior to launching is accomplished via the Remote 
Vehicle Checkout Facility (RVCF) at KSC. The RVCF receives telemetry and 
transmits commands to the payload, via SGLS, and verifies the Orbiter's 
FM Communication System compatibility with the AF Satellite Control Facility 
(SCF). 

DOD payload commands are transmitted to the .DOD payload(s) and lUS/SSUS 
at KSC via the following paths: 

a. Dedicated payload safing commands for caution and warning (C and W) 
from DOD Payload Processing Facility via Launch Control Center 
(LCC) to Pad. The command data transfer takes place using the 

T = 0 payload umbilical cable. 

b. Commands are transmitted over DOD Remote Vehicle Checkout Facility 
(RVCF) at KSC via Space-Ground Link Subsystem (SGLS) PM link to 
Pad and DOD payload and/or lUS. 

c. Commands are transmitted over MCC-H via NASCOM, TDRS, MILA and 
LCC to Pad. All DOD commands expected to be sent over MCC-H are 
coordinated beforehand with MCC-H. Command validation and verifi- 
cation is confirmed at the MCC-H and command telemetry response 
(verification) is confirmed at the DOD POCC. MCC-H can perform 
command lockout for invalid DOD commands and DOD can make sure 
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Figure 2.2-5. DOD Payload Coitmand 
Interface, Prelaunch 
Phase, KSC 
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NASA win not transmit NASA commands to DOD payloads. This link 
is only used for backup. 

d. Prestored commands on the Orbiter are activated over any of the 
three links. 

All commands are two-stage; DOD-POCC transmits command to payload com- 
mand buffer, the command is returned over forward telemetry link to POCC 
for validation and enable command is transmitted to payload from POCC. 

Communications with payload and lUS/SSUS vvhen payloads are in the 
Orbiter on the Pad is either over a hardwired link, via the Payload Data 
Interleaver or MDM to computers on the Shuttle. The OOD POCC must obtain 
permission from MCC-H and LCC to transmit commands to the payloads. 

2.2. 2.3 Health Telemetry Interfaces 

2. 2. 2. 3.1 JSC Payload Health Telemetry Interface, Prelaunch Phase, KSC 
(Figure 2.2-6) 

The flow of Payload Health Telemetry is summarized in Figure 2.2-6. In 
the Spacelab checkout phase before removal to the pad. Health Telemetry 
data is received directly from the Spacelab and/or payloads at the LCC 
Payload Station Console. After removal to the pad, Health Telemetry is 
received over the hardwired link from the Orbiter MDM via the Ground 
Support Equipment and PPF to the LCC Payload Station Console. For end-to- 
end checkout. Health Telemetry will be transmitted over MILA/GSTDN either 
directly over NASCOM ground link or via the TORS link and NASCOM to MCC-H 
where the Spacelab and payload Health Telemetry is demultiplexed from 
Orbiter telemetry and forwarded to the JSC POCC for processing and display. 
The Health Telemetry, where required, will also be forwarded from the JSC 
POCC to remote POCC's. 

2. 2. 2. 3. 2 GSFC Payload Health Telemetry Interface, Prelaunch Phase, KSC 
(Figure 2.2-7) 

2. 2. 2. 3. 2.1 Payload Arrival, Installation, and KSC Interface Activity 

The payload arrival, installation, and KSC interface activities for 
the GSFC payload Health Telemetry interfaces are similar to those described 
for the GSFC payload command interfaces in Sections 2. 2. 2. 2. 2.1, 2. 2. 2. 2. 2. 2, 
and 2. 2. 2. 2. 2. 4 of this report. 
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Figure 2.2-6. JSC Payload Health 
Telemetry Interface, 
Prelaunch Phase, K5C 
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2.2,2,3o2.2 Interface Testing NOT 

Payload preinstallation testing at KSC will be conducted in a closed 
loop between the payload and the payload GTE including the P6S as the focc 
point of test operations as shown in Figure 2.2-7. Tests will be conduct« 
in the PPF to verify safe payload arrival at the launch site. The POCC 
will require data links to support commands and data flow and to verify 
communication links from KSC to GSFC. These links will be required to 
support POCC activities later in the payload flow. All the links envi- 
sioned as necessary to support the payload activity are given in Table 2.; 

Prior to moving the payload from the PPF to the Orbiter Processing 
Facility (OPF) or the Payload Changeout Room (PCR) for installation in the 
Orbiter, a POCC-PGS-payload interface verification check will be made to 
ensure that the POCC can receive and process payload Health Telemetry 
(non- interleaved) direct data. 

Testing with the RF links will be performed in conjunction with the 
Orbiter avionics while the payload is still in the PPF and the Orbiter is 
in the OPF. Payload Health Telemetry will be transmitted from the PPF to 
the OPF and interleaved with the Orbiter 128 kbps telemetry bit stream. 
This bit stream will be relayed to the POCC via MILA and the MCC. 

Just prior to moving to the OPF, the onboard computer in the command 
and data handling module of the MMS will be loaded with flight program (ot 

verified if the program has been previously loaded). Once the memory is 

loaded and verified at the PPF, it is not anticipated that any further 
memory loads will be necessary. However, the memory will be dumped and 
verified at least one additional time prior to launch. After the payload 
arrives at the OPF and is installed in the Orbiter, the PGS will monitor 
payload Health Telemetry directly as available via the T = 0 umbilical. 
The POCC will also be able to monitor the payload Health Telemetry either 
directly via the PGS through NAS COM or directly via the Orbiter 01 link. 
The PGS will command directly via the T = 0 umbilical and the POCC can 
command either directly or via the Orbiter avionics. When the Orbiter 

avionics are available, the POCC should be able to back up the PGS and 

monitor the payload via the Orbiter 01 link. 
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After payload installationVnd completion of interface testing, 

''further monitoring will be done by both the PGS and the G5FC POCC. Payload 
data flow will be the same at the pad as it was for OPF-installed payloads. 

It is anticipated that all critical payload/Orbiter interface testing will 
be verified prior to arriving at the launch pad for payloads installed in 
the OPF. For pad-installed payloads, interface testing will be performed 
imme^liately following installation. Most of the launch pad activity after 
installation and prior to the terminal count should consist mainly of 
payload monitoring. 

After the payload is installed in the Orbiter at the OPF or at the 
pad, it is a requirement to check out the payloadrto-Ku-band interface if 
such a communications system is aboard the payload. This is to be an end- 
to-end test for transmission of payload commands and receipt of telemetry 
between the POCC, MCC, 6STDN, TDRSS east, Orbiter, and payload. The PGS 
will process the demodulated Ku-band data to assist the interface 
verification. 

Aft^r the payload is installed in the Orbiter at the OPF or at the 
pad, tho POCC software will verify the hardline connection for commands 
through the Orbiter avionics system. 

2. 2, 2, 3. 3 JPL Payload Health Telemetry Interface, Prelaunch Phase, KSC 
(Figure 2o2-8) 

2, 2. 2. 3. 3,1 Payload Arrival and Installations 

The payload arrival and installations interface activities for the JPL 
payload Health Telemetry interfaces are identical to those described in 
Sections 2, 2. 2. 2. 3.1 and 2. 2, 2. 2. 3. 2 of this report. 

2. 2, 2. 3, 3. 2 Interface Testing 

The operations concept for interface testing of the payload Health 
Telemetry at KSC is depicted in Figure 2,2-8, As described in Section 
2. 2. 2.?. 3. 3 of this report, this operation' concept assumes that preliminary 
testing has been performed and that remote monitoring and control will be 
retained in Building AO as described in the reference section. In addition, 
paylpad Health Telemetry is directly transferred to the AO via an S-band link. 
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Figure 2.2-8. OPl- Payload Healtli 
Telemetry Interface, 
Prelaunch Phase, (CSC 
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S-band and X-band link verification is performed with the cargo doors 
open and the Health Telemetry signals are radiated to the MLP where they 
are reradiated to MILA and MIL-71. 

The flow of Health Telemetry from the payload to the JPL POCC is by 
the following several paths: 

1. Payload Health Telemetry is radiated directly via S-band and 
X-band to MIL-71 for transmission by NASCOM directly to JPL (AO) 

.. and MCCC (JPL POCC). 

2 . Payload Health Telemetry is multiplexed with the lUS and via an 
S-band link to MILA and then NASCOM to MCC-H where the payload-IUS 
Health Telemetry is demultiplexed and the payload portion of the 
data stream is transferred via NASCOM to JPL POCC for processing 
and display. 

3. Payload-IUS Health Telemetry is multiplexed with the Orbiter and 
via either S-band or Ku-band to MILA. The telemetry data is then 
transferred to MCC-H via the NASCOM where the Orbiter telemetry 
data stream is demultiplexed and the payload portion of the data 
stream is transferred via NASCOM to the JPL POCC for processing 
and display. 

4. Payload "Bent Pipe" data from the Orbiter is transferred via 
Ku-band to the MILA, then relayed to the JPL POCC via the TDRSS- 
NASCOM. 


5. The TDRSS link serves as an alternate link for MILA. 

2. 2. 2. 3.4 DOD Payload Health Telemetry Interface, Prelaunch Phase, KSC 
(Figure 2.2-9) 

The Payload Health Telemetry is normally transmitted directly to the 
DOD POCC from the DOD Payload Processing Facility (PPF) as shown in 
Figure 2.2-9. During the latter phases of prelaunch checkout at the Pad, 
the communications link via MILA, TDRSS, NASCOM and MCC-H is checked out. 
This link ensures both command and telemetry response compatibility of 
communications between the Payload and DOD POCC. The Payload Health 
Telemetry includes command verification and payload status information. 

At KSC, the payload telemetry is processed by the DOD Payload Process- 
ing Facility and monitored in the Launch Control Center at the Payload 
Station Console. lUS-Payload and Payload Health Telemetry can also be 
transmitted directly over the FM transmitter to the PPF, or via the Remote 
Vehicle Checkout Facility to STC and the DOD POCC. 
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Figure 2.2-9, DOD Payload Health 
Telemetry Interface, 
Prelaunch Phase, KSC 
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2. 2.2.4 ' Science Telemetry Interfaces 

2. 2. 2. 4.1 JSC Payload Science Telemetry Interface, Prelaunch Phase, KSC 
(Figure 2.2-10) 

The payload Science Telemetry flow is shown in Figure 2.2-10. Similar 
to Health Telemetry in the prelaunch phase, Spacelab and payload data is 
initially, during the Spacelab checkout phase, transmitted from Spacelab 
to the LCC Payload Station Console. Selected Science Telemetry will be 
multiplexed with Orbiter data during the on-pad phase and transmitted over 
the MDM to GSTDN and either over ground links via NASCOM or using TORS 
and the Ku-band link to the TDRSS ground station where it may either be 
multiplexed with tracking data for transmission over a wideband T1 channel 
to MCC-H or transmitted directly over a DOMSAT channel to MCC-H, MCC-H 
will subsequently demultiplex the Spacelab Science Telemetry data and for- 
ward it to the JSC POCC. The science data transmission between the JSC 
POCC and a remote POCC can be either via DOMSAT for higher bandwidth data 
or via landlines. 

2. 2. 2. 4. 2 JSC Payload Science Telemetry Interface, Prelaunch Phase, VAFB , 
(Figure 2.2-11) 

The flow diagram. Figure 2.2-11, depicts the flow of JSC Payload Science 
Telemetry data from a Spacelab mounted payload aboard an Orbiter stationed 
at the launch pad at VAFB. 

Similar to JSC Payload Science Telemetry handling at KSC, all detailed 
Wideband Science Telemetry will have been previously checked out at the 
Launch Control Center Payload Station Console at VAFB prior to moving the 
Orbiter/Spacelab to the pad at VAFB. Only selected Science Telemetry multi- 
plexed with Orbiter data will be transmitted from the Orbiter to the Ground 
Support Equipment which transmits the data to the TDRSS ground station over 
the TDRSS Ku-band link. 

Identical to telemetry transmission from the Spacelab at KSC to the 
JSC POCC, the science data transmission between the JSC POCC and a remote 
POCC can be either via DOMSAT for higher bandwidth data or via Tandlines. 
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2. 2. 2. 4. 3 GSFC Payload Science Telemetry Interface, Prelaunch Phase, KSC 
(Figure 2.2-12} 

Science Telemetry aboard the GSFC payloads is handled identical to 
the payload Health Telemetry using the same RF links. There is, however, 
an additional RF link employed between the TDRSS Ground Segment and the 
GSFC POCC. This additional RF link is the DOMSAT (Domestic Satellite) 
which parallels the NASCOM/MCC-H path between the TDRSS and the GSFC POCC. 
This concept is shown in Figure 2-11. 

2. 2. 2.4.4 JPL Payload Science Telemetry Interface, Prelaunch Phase, KSC 
(Figure 2.2-13) 

The flow diagram. Figure 2.2-13, depicts the flow of Payload Science 
Telemetry data from a JPL payload located aboard the Orbiter at the KSC 
launch pad to its associated JPL POCC. Payload telemetry distribution at 
KSC is also transmitted to the Payload Processing Facility (PPF) and the 
Payload Station Console (PSC) in the Launch Control Center (LCC). 

The Payload Science Telemetry is normally transmitted back to the JPL 
POCC via the NASCOM ground link; however, during the latter phases of the 
prelaunch checkout at the pad, the communication link via MILA through TDRSS 
is checked out. This link ensures both command and telemetry_response com- 
patibility of the communications between the payload and its POCC. The 
Payload Science Telemetry is defined as including command verification and 
payload status. Command verification is the Payload Telemetry response to 
a command. Payload status is indicated on the flow diagram as PL TLM. 

The remote POCC can receive the same telemetry as the POCC since it 
has the capability of generating commands and requires the telemetry for 
command verification and execute. 

At KSC the Payload Telemetry is processed by the Payload Processing 
Facility and monitored in the Launch Control Center at the Payload Station 
Console. 

All payload telemetry is multiplexed with the lUS and Orbiter Telemetr)- 
to simulate the actual multiplexing used during Operational Flight. 
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2. 2. 2. 4. 5 DOD Payload Experiment Data Flow, Prelaunch Phase, KSC 
(Figure 2.2-14) 

The Payload Experiment Telemetry is transmitted directly from the 
payload in the Orbiter, over an umbilical hardline to the DOD Payload 
Processing Facility. Therewill be no NASA interfaces for the DOD Experi- 
mental Data Telemetry Link. 

The DOD payload experimental data flow during the prelaunch phase is 
shown in Figure 2.2-14. 
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Figure 2.2-14. Payload Experiment Data Flow, 

;^Prelaunch Phase, DOD Payload, KSC 
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2.2.3 Operational Activities 

2. 2. 3.1 General 

Operational activities for this study include those payload operations 
for Payload Commands,, Payload Health Telemetry, and Payload Science Telem- 
etry for JSC, GSFC, JPL, and DOD payloads after launch and including ascent, 
on-orbit, and deployment phases. These operations will include those payload- 
associated operations while the payload is: 

1. In initial free flight 

2. Attached to the lUS/SSUS 

3. Attached to the Orbiter in orbit. 

2. 2. 3. 2 Command Interfaces 

2. 2. 3. 2.1 OSC Payload Command Interface, Operational Phase (Figure 2.2-15) 

Figure 2.2-15 shows the command data flow from a JSC POCC through the 
Orbiter to the Spacelab and Spacelab payloads. Payload commands are 
transmitted in standard NASCOM format to MCC-H where payload commands are 
multiplexed with forward link data destined for the STDN ground station 
to GSFC on a 1.544 Mbps NASCOM link, GSFC (NASCOM) performs a message 
switch function and routes the command blocks to the designated station 
based on a station ID that is located in the overhead of the NASCOM command 
data block. 

The uplink GSTDN station validates the command message, adds a 32-bit 
sync and station ID word, and time division multiplexes the command data 
with voice. The station then transmits a 72 Kbps (high bit-rate) or a 
32 Kbps (low bit-rate) command and voice data stream to the Orbiter. 

Commands are subsequently retransmitted from the Spacelab and payloads by 
the Orbiter to both MCC-H and the Spacelab POCC for verification and logging 
before a command execute command is transmitted to the payload. Commands 
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are validated* only at MCC-H before a command execute message is trans- 
mitted to the Spacelab and payToad(s) from the POCC. A list of Spacelab 
commands which could constitute a hazard to the Orbiter and payloads. is 
identified prior to flight and inhibited during designated flight phases. . 
The "hazardous command" protection is thus provided by MCC-H,. The uplink 
GSTDN station also records the uplink command data and transmits a command 
history consisting of readback of commands received, including time tags 
with' site command acceptance to the JSC POCC, in case of loss of signal 
(LOS) from the Orbiter. 

If the command data is to be routed to the TDRSS ground station, 

MCC-H will accomplish all of the functions that the GSTDN station performed. 
For thd' TDRSS, MCC-H multiplexes the 2 Kbps Spacelab command data' from the ’ 
JSC POCC with Orbiter data and outputs the 11 Kbps or the 32 Kbps in the 
Orbiter uplink format. The TDRSS performs a throughput function by receiv- 
ing', the data stream over the NASCOM link and relaying it to the Orbiter, 

The TDRSS provides a command history such that MCC-H (and the JSC POCC) can 
determine the actual uplink data that was transmitted, with' associated . 
time. . ■ . . 

The command links from remote POCC's are identical to those described 
in the .prelaunch phase. 


*Command validation is the bit-by-bit repeat of the command word duplicating 
the command stored in the Command Storage Buffer of the General Purpose 
Computer aboard the Orbiter. The command validation telemetry is demulti- 
plexed from the Orbiter operational instrumentation (01) data stream and 
transmitted to the JSC POCC in real time and in the same .format .and at 
the same rates as output from Spacelab. When the MCC-H confirms the 
command transmission, it then transmits a command confirmation message' 
back to the JSC POCC. The POCC then transmits an execute command. All 
commands stored fn the Orbiter's General Purpose Computer Command Buffer 
are transferred to the payload upon receipt of the execute command. 

Thus, Command validation indicates corrections of the command. Command 
verification , on the other hand, is the term used to indicate that the 
Command" has' actually been sent. 
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2. 2. 3. 2. 2 ‘6SFC Payload Interface, Operational .Phase (Figure 2,2-16) 

Command' data will be sent to' the GSFC p'ayloacl ‘during the opera'tioria'l^ 
phase (Ascent and On-orbit) with the commands' 6ri"gfhating with the 'GSFG"‘ ■ 

POCC or the remote POCC. 

During the ascent phase, it is not anticipated that any commands 
except safing commands will.be sent to the payload since the payload will 
be in a monitored -only- mode to ensure that it survives the .launch environ- 

' t 

ment and data saved for diagnostic purposes in the event an anomaly occurs. 

When the Orbiter reaches final orbit, then on-orbit operations begin 
and the payload will be commanded by the GSFC POCC. During deployment the 
POCC will check out the command capability. The flow of commands from the 
POCC to the payload is shown in Figure 2.2-16. 

Prior to deployment, RF communication will be established between the 
payload and the GSFC POCC via the TDRSS/GSTDN/NASCOM/MCC-H. Also, prior to 
the extraction of the payload umbilical, a direct RF link will tie established 
between the payload and the Orbiter. 

Following deployment, the Orbiter translates to a specified distance 
from the payload and maintains an escort operating mode. It is during the 
Escort Mode that the GSFC POCC performs a payload checkout using POCC- 
originated commands. 

Following successful deployment and payload checkout, normal payload 
operations begin with complete payload control from the GSFC POCC and with 
payload experiment data processing, orbit computation, attitude determina- 
tions, etc., accomplished via GSFC support facilities. Real-time commanding 
will be accomplished through the STDN/TDRSS. 

2. 2. 3. 2. 3 JPL Payload Command Interface, Operational Phase 

t 

JPL Payload Command Interfaces are depicted in Figure 2.2-17 which ' 
illustrates the three operating modes : 

1. Attached (Payload-IUS S'till physically attached to the ’Orbiter) . 

2 . Detached (Payload-IUS detached 'from -the Orb iteY). 

3. Free flight (Payload s^eparated -.from the-I,US')<. 
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In the "attached'' operating mode, payload commands generated in the 
JPL POCC are transferred to the MCC-H via NASCOM where they are multiplexed 
with forward link data and the validity of all Orbi ter- associated commands 
are confirmed. The confirmed commands are then transferred to the 
1.544 Mbps NASCOM link to the TDRSS ground segment and via the Ku-band link 
to the TORS. The TORS communicates the Payload/ I US/Orb iter commands to the 
Orb iter via SSA or KSA transmission links. 

Command verification is achieved by processing the demultiplexed 
telemetry data received from the Orbi ter via the TDRS-NASCOM-MCC-H-NASCOM 
link. 

In the "attached" operating mode, the Payload/IUS interfaces with the 
data system as follows: 

1. JPL POCC initiated commands are transferred to the MCC-H via 
NASCOM and to the Payload-IUS via the NASCOM-TDRS in the "attached" 
operating mode. 

2. JPL POCC initiated commands are transferred to the Orbi ter as in 
the "attached" operating mode and then transferred to the Payload- 
IUS over an S-band link. 

3. The alternate path routes the MCC-H processed commands via NASCOM 
and the GSTDN using a USB link to the Payload-IUS. 

Verification of commands is satisfied by processing the telemetry 
received from the return links and as processed by the MCC-H to strip the 
payload telemetry from the Orb iter telemetry stream. 

In the "Free Flight" operating mode, JPL POCC generated commands reach 
the payload via the JPL POCC-NASCOM-MCC-H-NASCOM-QSTDN path as described 
for the detached operating mode. In addition, command data is received 
directly via JPL POCC/NASCOM/DSN. Command verification is obtained by 
processing the directly received payload data {via the DSN-NASCOM return 
link) . 

2, 2. 3, 2. 4 DOD Payload Command Interface, Operational Phase (Figure 2,2-18) 

Command data from the DOD POCC is transmitted via NASCOM to MCC-H for 
verification and validation. Validated commands are subsequently transmit- 
ted via NASCOM and GSTDN or TDRSS END SEGMENT to the Orbiter (Figure 2.2-18). 
The commands are stored in the command data buffer onboard the Orbiter and 
retransmitted over the return link via TDRSS or GSTDN and NASCOM to the 


2-117 SMamawG page blank 


not FILM£» 





\ 





Figure 2.2-18. DOD Payload Comnand 
Interface, Operatior 
Phase 


PASS blank not FIL^fS* 


2-119 











MCC-H where the forward link command validation data is demultiplexed from 
telemetry data and forwarded via NASCOM to DOD for command validation. 

The command message onboard the Orbiter is subsequently enabled from 
the DOD POCCs and a command enable message is transmitted over the forward 
link to the Orbiter. 

Safing commands from the Orbiter will be transferred to the payload 
via discrete hardwire signals and may originate either onboard the 
Orbiter or at the POCC/STC. All payload checkout commands will either be 
transmitted directly from the SCF (via SOLS) to the payload antenna or from 
the Orbiter via hardware with voice coordination to the STC. After the 
payload is deployed, DOD assumes full control of the payload operation, 
while NASA continues to maintain control of the Orbiter. 

The primary link between MCC-H and the TDRSS Ground Station is a 
1.544 Mbps line. Command data may also be transmitted via GSFC over a 
1.544 Mbps primary line or a 224 Kbps backup line to the TDRSS Ground 
Station. 

2. 2. 3. 3 Health Telemetry Interfaces 

2. 2. 3. 3.1 JSC Payload Health Telemetry Interface, Operational Phase 
(Figure 2.2-19) 

The Payload Health Telemetry data flow from the Spacelab“pallet and/or 
manned module payloads is shown in Figure 2.2-19. Spacelab Health Telemetry 
data is transmitted either directly over GSTDN or TORS and the TDRSS Ground 
Station via NASCOM to MCC-H. The telemetry data has been multiplexed with 
Orbiter telemetry onboard the Orbiter and is subsequently demultiplexed 
at MCC-H. The telemetry link from the Orbiter Payload Data Interleaver 
(PDI) is limited to 64 Kbps. STS Flight Operations at MCC-H will process 
the minimum standard Spacelab and payload housekeeping data received from 
the operational data stream as well as monitor Spacelab systems, contin- 
gency support and systems support for unattended operations. The demulti- 
plexed Payload Health Telemetry data is also transmitted to the JSC POCC 
by MCC-H. 

2. 2. 3. 3. 2 GSFC Payload Health Telemetry Interface, Operational Phase 
(Figure 2.2-20) 

The flow diagram, Figure 2.2-20, depicts the flow of Payload Health 
Telemetry data from a GSFC Payload either in Free Flight (FF), attached 
to an lUS, or attached to the Orbiter, to the GSFC POCC. 
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When a payload without an lUS is attached to the Orbiter, the Payload 
Health Telemetry is multiplexed directly with the Orbiter Downlink data in 
the Orbiter Multiplexer Demultiplexer (MDM). However, when a payload is 
attached to an lUS aboard the Orbiter, the Payload Telemetry is first multi- 
plexed with the IDS TLM which is then transferred to the Orbiter MDM and 
multiplexed with the Orbiter data, the sum total being PL-IUS-ORBITER data. 
This data is transmitted via SSA or KSA to the TDRSS or via Unified S-band 
(USB) to GSTDN and then transmitted via NASCOM to MCC-H where the payload 
data is demultiplexed and formatted for transmission via NASCOM to the 
GSFC POCC. MCC-H also processes and displays the Payload Telemetry for 
Payload Health Monitoring and performs command validation and verification. 

When the lUS and attached payload are deployed from the Orbiter, the 
Payload Telemetry is multiplexed with the I US Telemetry and transmitted via 
links similar to those used by the Orbiter data discussed above. The MCC-H 
processes, displays and retransmits this data in a similar manner. 

In Free Flight (FF) the Payload Telemetry uses the Multiple Access (MA), 
S-Band Single Access (SSA), or Ku-Band Single Access (KSA) links to the 
TDRSS and uses the Unified S-Band (USB) link to the GSTDN. The FF telemetry 
data is distributed via the NASCOM network directly to the POCC, by-passing 
the MCC-H. 

The Payload ‘Health Telemetry is transmitted to the remote POCC from 
the GSFC POCC via convenient landlines. The bandwidth of this data does 
not necessitate the use of a DOMSAT. 

2, 2, 3. 3, 3 JPL Payload Health Telemetry, Operational Phase (Figure 2.2-21) 

The flow diagram. Figure 2.2-21, depicts a concept of the flow of JPL 
Payload Health Telemetry data from a JPL Payload either aboard an Inflight 
Orbiter, attached to an lUS or in Free Flight. 

When the PL/IUS is aboard the Orbiter, the payload data is multiplexed 
with the lUS data which in turn is multiplexed with the Orbiter downlink 
data. This multiplexed data (PL-IUS-ORBITER) is transmitted from the 
Orbiter to either the TDRSS or GSTDN and distributed via NASCOM to the 
MCC-H where it is demultiplexed and the payload data is forwarded to the 
JPL POCC. 
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When the lUS-PL is deployed from the Orbiter, the Payload Health data 
is still multiplexed with the I US,, data (PL-IUS). This data is then trans- 
mitted direct to the TORS or to 'the GSTDN via a Remote Tracking Station. 

J-* 

The TORS link is only used immediately following deployment from the 
Orbiter because the lUS-PL will soon get out of range of the TORS. 

The payload in Free Flight will only communicate via the GSTDN 
directly back to the JPL POCC (bypassing the MCC-H), The presently anti- 
cipated bandwidth of the JPL Health Telemetry- does not require the use of 
a DOMSAT by NASCOM. 

2,‘2.3.3.4 DOD Bayload Health Telemetry Interface, Operational Phase 
(Figure 2.2-22) 

The lUS-satell ite payload is hardwired to the Orbiter, with- the 
satellite tel emetry. and commands being hardwired directly through the lUS 
to the Orbiter. There are up to 50 s'afety-critical parameters from the com- 
bined lUS-satell ite 'configuration that' are hardwired directly to the C and W 
system in the Orbiter. Up to 36 corresponding payload safing commands 
are hardwired from, the Orbiter. General status monitoring telemetry data 
(possibly including the Caution and Warning)' is formatted into a serial 
digital data signal and sent to the Orbiter for interleaving into the 
Orbiter- to-ground downlink at data rates from 250 bps to 64“Kbps (nominally 
16 Kbps), Figure 2.2-22. Formatted and encrypted satellite telemetry data at 
rates up to 256 Kbps is forwarded by the I US for relay by the Orbiter FM 
transmitter to the AFSCF RTS. The Orbiter communications with the ground 
uses either S-band or Ku-band links to the TORS or S-band links to the GSTDN. 
Downlink data containing voice, payload telemetry, and Orbiter telemetry is 
sent to the MCC/JSC at 96 Kbps (low data rate) or 192 Kbps (high data rate). 
The Orbiter's FM S-band transmitter relays satellite data directly to the 
Air Force Satellite Control Facility (AFSCF) Remote Tracking Station (RTS) 
when line-of-sight conditions exist. 

There are at least two voice channels and a data channel on the 
MCC/JSC to POCC/STC communications link. One voice channel is the party 
line circuit among the Orbiter, MCC, and POCC, and the other is a dedicated 
voice channel between the POCC and DOD Payload Officer at the MCC. The 
return link data channel carries the- payload housekeeping data and payload 
related Orbiter data from' th“e 'Orbiter telemetry. 
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The system expanded from Phase IB to accommodate Shuttle launches 
from VAFB still comprises principally the Phase lA elements. However, 
with VAFB Initial Operating Capability (IOC), additional communications 
segments become operative. These include: 

a. VAFB-to-MCC Communications, Mission/Flight coordination is pro- 
vided for VAFB launch and landing operations. Voice communica- 
tion, system status, and Orbiter data updates are transferred 
between the LCC and MCC. 

b. VAFB-to-AFSCF Communications. DOD payload status telemetry 
and commands are transferred between the POCC and the Orbiter- 
installed payload. Voice coordination is maintained among 
launch support personnel at VAFB's Payload Processing Facility, 
VTS, LCC, and the POCC to provide overall payloacf mission 
support, 

2. 2. 3.4 Science Telemetry Interfaces 

2. 2. 3, 4.1 JSC Payload Science Telemetry Interface, Operational Phase 
(Figure 2.2-23) 

The flow diagram. Figure 2.2-23, depicts a concept of the flow of Pay- 
load Science Telemetry data from a JSC payload located either aboard an 
inflight Orbiter, attached to an IDS, or in Free Flight. 

The flow and operational interfaces are identical to those described 
in Section 2. 2. 3, 3. 3 of this document. 

Medium- and high-rate Payload Science Telemetry is transmitted either 
via GSTDN or TDRSS via NASCOM to MCC-H (Figure 2.2-23J . The multiplexed 
Spacelab, payload and Orbiter data may either be multiplexed with tracking 
data at the TDRSS Ground Station for transmission over a wideband T1 chan- 
nel to MCC-H or transmitted directly over a DOMSAT channel from the remote 
site to the JSC POCC. The DOMSAT link may also be used to transmit the 
Payload Science Telemetry to GSFC for near real-time data processing. The 
processed data is subsequently transmitted over a NASCOM link to the JSC 
POCC. The TDRS-NASCOM-MCC-H link is used for data rates 1.544 Mbps or less 
while the DOMSAT link is used for data rates up to 50 Mbps. 
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2. 2. 3. 4. 2 GSFC Payload Science Telemetry Interface, Operational Phase 
(Figure 2.2-24) 

During the operational phase, GSFC Payload Science Telemetry is • 
received at the GSFC POCC in the same manner as Payload Health Telemetry 
as described in Section 2.2.3. 3.1 of this report with some noted exceptions 
These exceptions are: 

1. While the payload is aboard the lUS/Orbiter, there are two 
communication paths to the POCC which are also used with the 
GSFC Payload Health Telemetry: 

a. TDRSS-NASCOM-MCC-H-POCC 

b. GSTDN-NASCOM-POCC 

In addition to these two paths, a third is provided by TDRSS 
re-routing the Science Telemetry data to the POCC via the 
DOMSAT link. 

2. When the payload has been separated from the lUS-Orbiter, then 
the Payload Science Telemetry has only one path to the POCC. 

That path is the GSTDN-NASCOM directly to the' POCC. 

This concept is depicted in Figure 2.2-24, 

2. 2. 3. 4. 3 JPL Payload Science Telemetry Interface, Operational Phase 
(Figure 2.2-25) 

The flow diagram. Figure 2.2-25, depicts the flow of Payload Science 
Telemetry data from the JPL payload to the associated JPL POCC. The data 
flow includes those interfaces while the JPL payload is either in Free 
Flight, attached to an lUS, or attached to an Orbiter. 

The flow shown is identical to the JPL Payload Health Telemetry 
described in Section 2, 2. 3, 3, 3. Reference is also made to Section 2. 2. 3. 2. 
JPL payload command interface for additional related information. 

2. 2. 3. 4. 4 DOD Payload Experiment Telemetry Data Flow, Operational Phase 
(Figure 2.2-26) 

All payload experiment data is transmitted directly, encrypted at 
256 Kbps, from lUS/payload and payload to DOD SCF Remote Tracking Stations 
and DOD POCC (Figure 2.2-26). 
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Figure 2.2-26. DOD Payload Experiment Telemetry Data Flow, Operational Phase 






2.2.4 Subtask 2B Conclusions and Recommendations 

The following conclusions and recommendations have been formulated 
from the performance of Subtask 2B: 

1. Provide end-to-end command verification link from the Orbiter to 
the POCC. This should permit standardization of data handling 
throughout the data system. 

2. Fully utilize the TDRSS and GSTDN during prelaunch checkout to 
verify end-to-end checkout and to assure end-to-end compatibility. 

3. Standardize the GSTDN and TDRSS for command data handling trans- 
parency. This standardization should serve to eliminate the 
costly changes which must be implemented at the several link 
junctions for each new payload or payload change. 

4. Provide for the demultiplexing of the composite I US-pay load data 
stream at MCC-H. This will minimize the number of Orbiter inter- 
faces and will serve to standardize the Orbiter interfaces to 
the payload and to MCC. Each payload user will receive only the 
data which concerns that user's specific payload. 

The above conclusions and recommendations may or may not be in 
consonance with prior study results or NASA proposed methods, but they 
represent TRW's findings in light of assumptions which were made to 
supplement NASA- and DOD-supplied information used on Subtask 2B. 
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2.2.5 Subtask 2B Summary 

In compliance with Study Subtask 28,’ this study report describes the 
POCC-payload interface for the several types of- payloads (payload organi- 
zations JSC, -GSPCj JPL, and DOD) in terms '6f the prelaunch and .opera- 
tional- phases. Communications flow diagrams for the. individual' command 
and telemetry (Health, Science) links' are detailed herein. Furthermore, 
each flow diagram is described to identify the several interfaces which 
will exist between the POCC and the respective payload. 

Formulated conclusions and recommendations based on a preliminary 
assessment of the communication flows by TRW are presented within the 
study guidelines and may not be in complete accord with the payload or- 
ganizations, JSC, nor KSC. Briefly stated, these conclusions and re- 
commendations are: 

a. Provide end-to-end command verification link, Orbiter to POCC's. 

b. Use TDRSS during prelaunch checkout. 

c. Standardize use of GSTDN and TDRSS for command data handling 
transparency. 

d. VAFB interface with NASCOM be provided by link to TDRSS NASCOM 
terminal . 

e. MCC provide for demultiplexing lUS and payload data. 

It was shown that with the exception of the DOD payloads, nearly 
all other payloads utilized the same communications paths, (i.e., either 
the T = 0 umbilical MLP-miA GSTDN-TDRSS-NASCOfl-MCC-H-NASCOM paths or both 
in communicating commands and telemetry between the payload and the POCC. 

Some of the noted exceptions are; 

a. JPL payloads also utilized the MIL-71 which is similar to DSN 
stations for command and telemetry communications during pre- 
launch and the DSN for operational. 

b. JSC and JPL payloads Health telemetry was provided to the JSC 
POCC and JPL POCC respectively via Bent Pipe from the TDRSS 
Ground Segment to the POCC, 

c. DOMSAT was shown as providing communication’ via the TDRSS ground 
directly to the POCC for JSC and GSFC payloads. 
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d. DOD payload prelaunch communications exception were identified 

as two additional links, (1). from- the RVCF (Remote Vehicle Check- 
out Facility to the f^ew Hampshire station to, STC and (2) from 
the PPF directly to the STC. 

e. DOD payload operational communications are. shown as having- 
direct communications with Orbiter and lUS-PL, in addition to 
the TDRSS and GSTDN paths. 
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APPENDIX A 


ACDS 

. ACRONYMS AND ABBREVIATIONS 
Attitude Control and Determination Subsystem 

AEO 

Automated Earth Orbit ' 

AF 

Air Force 

AFSCF 

Air Force Satellite Control Facility 

AMPS 

Atmospheric, Magnetospheri'c, Plasmas-in-Space 

AO 

Announcement of (Flight) Opportunity 

ATL ' 

Advanced Technology Laboratory 

BESS 

Biomedical Experiment Satellite' System 

BPS 

Bits per Second- 

C and W 

Caution and Warning 

CMD 

Command 

CPU 

Central Processing -Unit ■ 

DOD 

Department of Defense 

DOMSAT 

Domestic Satellite- 

DP 

Data Processing 

DSN 

Deep Space Network 

EMI 

Electro-Mechanical Interference ' 

EOS 

Earth Observation Satellite 

FF 

Free Flight 

FFTO 

Freeflyer Teleoperator 

FM 

Frequency Modulated 

FSS 

Flight Support System 

GEO . 

Geosynchronous Earth Orbit 

GND 

Ground 

GSE 

Ground Support Equipment 

GSFC 

Goddard Space Flight Center 
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GSTDN 

Ground Portion of Space Flight Tracking and Data 
Network (STDN Ground Stations) 

GTE 

Ground Test Equipment 

GTE 

Ground Time Elapse 

HEA 

High Energy Astrophysics 

HEAO 

High Energy Astrophysics Observatory 

ID 

Identification 

I/O . 

Input/Output 

IOC 

Initial Operating Capability 

lOM 

Integrated Operations Manager 

I US 

Interim Upper Stage 

IVE 

Interface Verification Equipment 

OPL 

Jet Propulsion Laboratory 

JSC 

Lyndon B. Johnson Space Center 

KBPS 

Kilobits per Second 

KIPS 

Thousand Instructions per Second 

KHZ 

Kilo Hertz 

KSA 

Ku-Band Single Access 

KSC 

John F. Kennedy Space. Cent< 

LA6E0S 

Laser Geodynamic Satellite 

LCC 

Launch Control Center 

LEO 

Low Earth Orbit 

LIDAR 

Light Detection and Rangin 

LOS 

Loss of Signal 

LPS 

Launch Processing System 

LS 

Life Science 

MA 

Multiple Access 

MBPS 

Megabits per Second 

MCC 

Mission Control Center 



MCCC 

Mission Control and Computing Center (JPL) 

MCC-H 

'Mission Control Center-Hoiiston 

MDM 

Mul ti pi exer-Deniul ti pi exer 

MEM 

1 

Module Exchange Mechanism 

MIL-71 

Merritt Island, Florida (No. 71) 

MILA 

Merritt Island Launch Area (A STDN Ground Station) 

MLP 

Mobile Launcher Platform 

MMI 

Man'-Machine' Interface' 

NASA 

National Aeronautics and Space Administration 

NASCOM 

NASA World Wide Communications Network 

NOCC 

Network Operation Control Center 

OFT 

Orbital Flight Test ■ 

01 

Operational Instrumentation 

OPF 

Orbiter Processing Facility 

PC 

Payload Coordinator' 

PCR 

Payload Changeout Room 

PCS 

Payload Checkout Stand 

PDI 

Payload Data Interleaver 

PCS 

Payload Ground Station 

PL 

Payload 

POC 

Payload Operations Center 

POCC 

Payload Operations Control Center 

PPF 

Payload Processing Facility 

PS 

Payload Station 

PSC 

Payload Station Console 

RF 

Remote Frequency 

RFI 

Radio Frequency Interference 

RTS 

Remote Tracking Station 

RVCF 

Remote Vehicle Checkout Facility 
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SAEF 

SCF 

SEOPS 

SGLS 

SI 

SL 

SO 

SPMS 

SPOCC 

SSA 

ssus 

ST 

STC 

STD 

STDN 

STP 

STS 

TORS 

TDRSS 

TLM 

USB 

UV 

VAFB 

VTS 


Sterilization, Assembly, and Encapsulation Facility 
SatelTite Control Facility 

Standard Earth Observations Package for Shuttle 

Space-Ground Link Subsystem 

Solar Instrument 

Spacelab 

Solar Physics 

Special Purpose Manipulator System 
Standard Payload Operations Control Center 
S-Band Single Access 
Spin Stabilized Upper Stage 
Space Telescope 

Satellite Test Center (Sunnyvale/DOD) 

Standard 

Space Flight Tracking and Data Network 
Space Test Program (Classified DOD Payload) 

Space Transportation System 

Tracking Data Relay Satellite 
Tracking Data Relay Satellite System 
Telemetry 

Unified S-Band 
Ultraviolet 

Vandenberg Air Force Base 
Viewfinder Tracking System 
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